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INCLUDING THE DETERMINATION ASSOCIATION WHICH IS 
NECESSARY TO RETRIEVE THE INSTANCE OF THE ASSOCIATED 
OBJECT FROM THE DATABASE 

17008 



LOADING THE OBJECT IDENTIFIER WHEN THE BUSINESS 
OBJECT STARTS 



17010 



DETERMINING A LOCATION OF THE INSTANCE OF THE ASSOCIATED 
OBJECT ON THE DATABASE FROM THE OBJECT IDENTIFIER 

17012 



RETRIEVING THE INSTANCE OF THE ASSOCIATED OBJECT FROM 

THE DATABASE 

17014 



Fig. 170 
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17100 



RETRIEVING AN OBJECT FROM A DATA STORE 



1Z102 



CACHING AN OBJECT 



17104 



ASSIGNING A UNIQUE OBJECT IDENTIFIER TO THE OBJECT 



17106 



MAPPING THE OBJECT IDENTIFIER TO A REPRESENTATION OF THE 
OBJECT IN A DICTIONARY 

17108 



RECEIVING A REQUEST FOR A REFERENCE TO THE OBJECT 



17110 



RETRIEVING THE OBJECT IDENTIFIER OF THE OBJECT FROM THE 

DICTIONARY 

17112 



ASSOCIATING THE REQUESTED REFERENCE WITH THE 
REPRESENTATION OF THE OBJECT STORED IN THE DICTIONARY 

17114 



Fig. 171 
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17300 



ACCESSING A PERSISTENT OBJECT BEING DEVELOPED 



17302 



DETACHING A STATE OF THE PERSISTENT OBJECT INTO A 
SEPARATE STATE CLASS, WHEREIN THE STATE CLASS SERVES 
AS A CONTRACT BETWEEN A LOGIC DEVELOPMENT TEAM 
AND A DATA ACCESS DEVELOPMENT TEAM 

17304 



LIMITING LOGIC DEVELOPMENT BY THE LOGIC DEVELOPMENT 
TEAM TO DEVELOPING BUSINESS LOGIC 



17306 



RESTRICTING DATA ACCESS DEVELOPMENT BY THE DATA 
ACCESS DEVELOPMENT TEAM TO PROVIDING DATA CREATION 
RETRIEVAL, UPDATING, AND DELETION CAPABILITIES 

17308 



Fig. 173 
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17400 



PROVIDING AN OBJECT WITH AT LEAST ONE MISSING ATTRIBUTE 



17402 



RECEIVING A REQUEST FROM AN APPLICATION FOR THE OBJECT 



17404 



ALLOWING ACCESS TO THE ATTRIBUTES OF THE OBJECT BY THE 

APPLICATION 



17406 



PROVIDING A WARNING UPON AN ATTEMPT TO ACCESS THE 
ATTRIBUTE OF THE OBJECT THAT IS MISSING 



17408 



Fig. 174 
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17506 



Fig. 175 



Account 




17600- 



struct accountPaymentData 

char accountID 
customerlD 
money serviceCharges, 
balanceDue, 
amountPaid; 
Date paymentDate; 
int creditCardNum, 
checkNum; 
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17900 



PROVIDING A GROUP OF BUSINESS OBJECTS NECESSARY 
FOR A TRANSACTION 



1Z9Q2 



BATCHING LOGICALLY-RELATED REQUESTS RECEIVED FROM THE 
BUSINESS OBJECTS INTO A SINGLE NETWORK MESSAGE, WHEREIN 
ONE OF THE REQUESTS IS A PARENT REQUEST 17QQ4 



RECEIVING A REGISTER THAT AT LEAST ONE OF THE REQUESTS IS 
DEPENDENT UPON THE RESPONSE DATA FROM THE 

PARENT REQUEST 17906 



SENDING THE NETWORK MESSAGE ACROSS A NETWORK 



17908 



UNBUNDLING THE REQUESTS FROM THE NETWORK MESSAGE 

1ZM 



RECEIVING A RESPONSE TO THE PARENT REQUEST 



12912 



DIRECTING DATA FROM THE RESPONSE TO THE PARENT 
REQUEST TO THE DEPENDENT REQUEST 



17914 



RECEIVING A RESPONSE TO THE DEPENDENT REQUEST BASED ON 
THE RECEIVED DATA FROM THE RESPONSE TO THE PARENT 

REQUEST 



Fig. 179 



05/06/2004, EAST Version: 1.4.1 



U.S. Patent Jun. 10, 2003 Sheet 114 of 123 US 6,578,068 Bl 
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4. Send Transaction: 
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c. Monthly Bill 274 
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18200 



PROVIDING A GROUP OF BUSINESS OBJECTS NECESSARY FOR 

A TRANSACTION 

18202 



MANAGING THE GROUP OF BUSINESS OBJECTS NECESSARY TO 
THE TRANSACTION IN A LOGICAL UNIT OF WORK 

18204 



CREATING A RECEIVER WHICH COMMUNICATES WITH THE 
BUSINESS OBJECTS IN THE LOGICAL UNIT OF WORK 



18226 



RECEIVING A MESSAGE FOR THE BUSINESS OBJECTS IN THE 
LOGICAL UNIT OF WORK 



18208 



DIRECTING THE MESSAGE TO THE RECEIVER, WHEREIN THE 
RECEIVER FORWARDS THE MESSAGE TO EACH OF THE 
BUSINESS OBJECTS IN THE LOGICAL UNIT OF WORK 

18210 



Fig. 182 
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18500 

I, 



PROVIDING A GROUP OF BUSINESS OBJECTS NECESSARY FOR 

A TRANSACTION 




18502 


■ 




MANAGING THE GROUP OF BUSINESS OBJECTS NECESSARY TO 
THE TRANSACTION IN A LOGICAL UNIT OF WORK 




18504 






GROUPING LOGICALLY-RELATED REQUESTS RECEIVED FROM 
THE LOGICAL UNIT OF WORK INTO A SINGLE NETWORK MESSAGE 




18506 




r 


STORING THE MESSAGE 




18508 
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SENDING THE MESSAGE UPON RECEIVING AN ORDER TO SEND 

THE MESSAGE 




18510 



Fig. 185 
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18800 



PROVIDING A GROUP OF BUSINESS OBJECTS NECESSARY 
FOR A TRANSACTION 



GROUPING LOGICALLY-RELATED REQUESTS RECEIVED FROM THE 

BUSINESS OBJECTS im 



OBTAINING AT LEAST ONE OF SORTING RULES AND SORT WEIGHTS 

18806 



SORTING THE REQUESTS IN THE MESSAGE AND PLACING THEM IN A 
SPECIFIC ORDER DETERMINED FROM THE ONE OF THE SORTING 
RULES AND THE SORT WEIGHTS 

18808 



. . 

BATCHING THE SORTED REQUESTS INTO A SINGLE MESSAGE 




18810 




t 



SENDING THE MESSAGE TO A DATA SERVER 

18812 



UNBUNDLING THE REQUESTS FROM THE MESSAGE IN THE SPECIFIC 

ORDER 

18814 



Fig. 188 
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19100 



PROVIDING MULTIPLE LOGICAL UNITS OF WORK OPERATING 
CONCURRENTLY, WHEREIN EACH OF THE LOGICAL UNITS OF 
WORK MANIPULATE AT LEAST ONE COMMON BUSINESS OBJECT 

19102 



CREATING A COPY OF THE COMMON BUSINESS OBJECT FOR 
EACH OF THE LOGICAL UNITS OF WORK SUCH THAT THE COPY 
OF THE BUSINESS OBJECT FOR ONE LOGICAL UNIT OF WORK 
BECOMES A SEPARATE INSTANCE FROM THE COPY OF THE 
BUSINESS OBJECT FOR ANOTHER LOGICAL UNIT OF WORK, 
WHEREIN EACH COPY OF THE BUSINESS OBJECT KNOWS THE 
CONTEXT OF THAT COPY OF THE BUSINESS OBJECT IN RELATION 
TO THE ASSOCIATED LOGICAL UNIT OF WORK < a < ni 



RECEIVING A REQUEST TO MAKE CHANGES TO A COPY OF THE 
BUSINESS OBJECT OF ONE OF THE LOGICAL UNITS OF WORK 
AND CHANGING THAT COPY OF THE BUSINESS OBJECT, 
WHEREIN THE OTHER COPIES OF TH BUSINESS OBJECT 

ARE NOT CHANGED 191Q6 



VERIFYING THAT ONLY ONE COPY OF THE BUSINESS OBJECT 
HAS BEEN CHANGED 

19108 



UPDATING THE COMMON BUSINESS OBJECT BASED ON THE 
CHANGE TO THE COPY OF THE BUSINESS OBJECT 



mm 



Fig. 191 
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LOAD BALANCER IN ENVIRONMENT 
SERVICES PATTERNS 

CROSS REFERENCE TO RELATED 
APPLICATIONS 

This application is related to United States Patent Appli- 
cations entitled A SYSTEM, METHOD AND ARTICLE OF 
MANUFACTURE FOR A DEVELOPMENT ARCHITEC- 
TURE FRAMEWORK Ser. No. 09/387,747, now 
abandoned, and A SYSTEM, METHOD AND ARTICLE OF 
MANUFACTURE FOR MAINTENANCE AND ADMIN- 
ISTRATION IN AN E-COMMERCE APPLICATION 
FRAMEWORK, Ser. No. 09/387,318, still pending both of 
which are filed concurrently herewith and which are incor- 
porated by reference in their entirety. 

FIELD OF THE INVENTION 

The present invention relates to system optimization and 
more particularly to organized request distribution to server 
components. 

BACKGROUND OF THE INVENTION 

An important use of computers is the transfer of infor- 
mation over a network. Currently, the largest computer 
network in existence is the Internet. The Internet is a 
worldwide interconnection of computer networks that com- 
municate using a common protocol. Millions of computers, 
from low end personal computers to high-end super com- 
puters are coupled to the Internet. 

The Internet grew out of work funded in the 1960s by the 
U.S. Defense Department's Advanced Research Projects 
Agency. For a long time, Internet was used by researchers in 
universities and national laboratories to share information. 
As the existence of the Internet became more widely known, 
many users outside of the academic/research community 
(e.g., employees of large corporations) started to use Internet 
to carry electronic mail. 

In 1989, a new type of information system known as the 
World-Wide-Web ("the Web") was introduced to the Inter- 
net. Early development of the Web took place at CERN, the 
European Particle Physics Laboratory. The Web is a wide- 
area hypermedia information retrieval system aimed to give 
wide access to a large universe of documents. At that time, 
the Web was known to and used by the academic/research 
community only. There was no easily available tool which 
allows a technically untrained person to access the Web. 

In 1993, researchers at the National Center for Supercom- 
puting Applications (NCSA) released a Web browser called 
"Mosaic" that implemented a graphical user interface (GUI). 
Mosaic's graphical user interface was simple to learn yet 
powerful The Mosaic browser allows a user to retrieve 
documents from the World- Wide- Web using simple point - 
and-click commands. Because the user docs not have to be 
technically trained and the browser is pleasant to use, it has 
the potential of opening up the Internet to the masses. 

The architecture of the Web follows a conventional client- 
server model. The terms "client" and "server" are used to 
refer to a computer's general role as a requester of data (the 
client) or provider of data (the server). Under the Web 
environment, Web browsers reside in clients and Web docu- 
ments reside in servers. Web clients and Web servers com- 
municate using a protocol called "HyperText Transfer Pro- 
tocol" (HTFP). A browser opens a connection to a server and 
initiates a request for a document. The server delivers the 
requested document, typically in the form of a text document 
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coded in a standard Hypertext Markup Language (HTML) 
format, and when the connection is closed in the above 
interaction, the server serves a passive role, i.e., it accepts 
commands from the client and cannot request the client to 

5 perform any action. 

The communication model under the conventional Web 
environment provides a very limited level of interaction 
between clients and servers. In many systems, increasing the 
level of interaction between components in the systems 

10 often makes the systems more robust, but increasing the 
interaction increases the complexity of the interaction and 
typically slows the rate of the interaction. Thus, the con- 
ventional Web environment provides less complex, faster 
interactions because of the Web's level of interaction 

35 between clients and servers. 

SUMMARY OF THE INVENTION 

A system and method are provided for distributing incom- 
ing requests from a user interface amongst a client and 

20 server components for optimizing usage of resources. 
Incoming requests are first received and stored by an activity 
module. The activity module instructs a client to handle a 
first subset of the requests and passes a second subset of the 
requests on to a utilization -based load balancer. The second 

25 subset of the requests are stored on the load balancer, and an 
availability of server components is determined and a listing 
of available server components is compiled. A determination 
is made as to which server component on the listing of 
available server components is most appropriate to receive 

30 a particular request. Each particular request of the second 
subset of requests is sent to the selected server component 
determined to be most appropriate to receive the particular 
request. 

In one embodiment of the present invention, the determi- 

35 nation of which server component is the most appropriate 
may be performed by allocating the requests on a round- 
robin basis whereby requests are assigned to consecutive 
server components by traversing along the listing of avail- 
able server components. In another embodiment of the 

40 present invention, the determination of which server com- 
ponent is the most appropriate may also include calculating 
an amount of utilization that each available server compo- 
nent or the client is currently experiencing. 

45 In one aspect of the present invention, the amount of 
utilization of each available server components may be 
calculated based on current CPU utilization, kernel sched- 
uling run-queue length, current network traffic at a node to 
the server component, and/or a number of requests currently 

5Q being serviced. 

In another aspect of the present invention, a request may 
be rerouted to a different available server component upon 
a crash of the selected server component. In a further 
embodiment of the present invention, the server components 

55 may be saved in a persistent store, wherein a check is made 
to determine whether a connection to a server component 
needs to be reestablished. 

BRIEF DESCRIPTION OF THE DRAWINGS 

60 The invention will be better understood when consider- 
ation is given to the following detailed description thereof. 
Such description makes reference to the annexed drawings 
wherein: 

FIG. 1 is a schematic diagram of a hardware implemen- 
ts tation of one embodiment of the present invention; 

FIG. 2 is a flow diagram illustrating a high level overview 
of an architecture; 
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FIG. 3 shows the dependencies of three architecture FIG. 35 illustrates how components are viewed from 

frameworks; different perspectives; 

FIG. 4 illustrates a delivery vehicle matrix; FIG. 36 shows a relationship between business compo- 

FIG. 5 illustrates a Delivery Vehicle Cube; nents and partitioned business components; 

FIG. 6 is a flow diagram depicting considerations to be 5 FIG. 37 shows how a Billing Business Component may 

taken into consideration when identifying the core technolo- create an invoice; 

gies to be used in an architecture; FIG. 38 illustrates the relationship between the spectrum 

FIG. 7 is a chart that can be utilized to determine whether ot Business Components and the types of Partitioned Busi- 

to use Netcentric technology; 10 ness Components; 

FIG. 8 is a chart that can be utilized to determine whether FIG. 39 illustrates the flow of workflow, dialog flow, 

to use Client Server technology; and/or user interface designs to a User Interface Component; 

FIG. 9 is a chart that can be utilized to determine whether FIG. 40 is a diagram of an Application Model which 

to use Host technology illustrates how the different types of Partitioned Business 

FIG. 10 illustrates the services of a Netcentric Architec- 15 Components might interact with each other; 

ture Framework in accordance with one embodiment of the FIG. 41 illustrates what makes up a Partitioned Business 

present invention; Component; 

FIG. 11 is a detailed diagram of some of the components p IG. 42 illustrates the role of patterns and frameworks; 

of the Netcentric Architecture Framework found in FIG. 10; FIG. 43 illustrates this Business Component Identifying 

FIG. 12 is a detailed diagram of other components of the Methodology including both Planning and Delivering 

Netcentric Architecture Framework found in FIG. 10; stages, 

FIG. 13 illustrates several components of the Presentation FIG 44 shows » U ^ Jf P**" 5 of »PpKcation c ° m - 

area of the Netcentric Architecture Framework; P onent for «« 0lder Entrv s y stem > 

r™^ ..j .„ , c i • /• nc FIG. 45 illustrates a traditional organization structure 

FIG. 14 illustrates several components of the Information ^ . . 4 . % . 4 ° „ 

„ . c iL 4 . 4 . r including an activities component, a credit/collections 

Services of the present invention; ..... r , . - 

r component, a billing component, and a finance component; 

FIG. 15 depicts the four major categories of functionality nG ^ es aQ iUustration of , horizontal iza . 

that the Network services provided by the Communications , . r 

_ , . r J tion model; 

Services are grouped into; ... . „ . , 

01 . 30 FIG. 47 illustrates a workcell organization approach 

FIG. 16 illustrates File Sharing services; including an activities component, a credit/collections 

FIG. 17 depicts Message Passing services; component, a billing component, and a finance component; 

FIG. 18 depicts Message Queuing services; FIG. 48 illustrates the Enterprise Information Architecture 

FIG. 19 illustrates Publish and Subscribe services; (EI A) model; 

FIG. 20 depicts Streaming, in which a real-time data 35 FIG. 49 illustrates a V-model of Verification, Validation, 

stream is transferred; and Testing; 

FIG. 21 illustrates CORBA-based Object Messaging; FIG. 50 portrays of a development architecture with a 

FIG. 22 illustrates COM Messaging; seamless integration of tools which can be plugged in for the 

„ „ ^ , capture and communication of particular deliverables; 

FIG. 23 represents CT1 Messaging; 40 ^ t J . *\ . 

FIG. 51 shows a design architecture with the compro- 

FIG. 24 illustrates various components of the Communi- mises made for ^ fg OQCn{ ^^0^ environ- 

cation Fabric of the present invention; ment' 

FIG. 25 illustrates the two categories of the Physical FI g 52 a lustrates a business process to object mapping; 

^ e ^ ia * 45 FIG. 53 is a diagram which illustrates a graph of resilience 

FIG. 26 illustrates several of the components of the tQ cnan g e . 

Transaction areas of the Netcentric Architecture Framework; RG ^ iUustrates a flowchart for a raethod for providing 

FIG. 27 illustrates various components of the Environ- an abstraction factory pattern in accordance with anembodi- 

mentat Services of the Netcentric Architecture Framework; mem of the present invention; 

FIG. 28 illustrates the Base Services of the Netcentric 50 piG. 55 illustrates a flowchart for a method for represent- 

Architecture Framework; mg a plurality of batch jobs of a system each with a unique 

FIG. 29 shows the major components of the reporting class in accordance with an embodiment of the present 

application framework; invention; 

FIG. 30 illustrates an example of how a custom report FIG. 56 illustrates a class diagram of the batch job 

architecture relates to a workstation platform technology 55 hierarchy; 

architecture; FIG. 57 illustrates an object interaction graph of a pos- 

FIG. 31 describes the relationships between the major sible implementation of the class diagram of FIG. 56; 

components of the report process and the report writer FIG. 58 illustrates a flowchart for a method for controlling 

process; fi0 access to data of a business object via an attribute dictionary 

FIG. 32 shows the module hierarchy for the custom report in accordance with an embodiment of the present invention; 

process; FIG. 59 iUustrates a flowchart for a method for structuring 

FIG. 33 depicts the various components of the Business batch activities for simplified reconfiguration in accordance 

Logic portion of the Netcentric Architecture Framework; with an embodiment of the present invention; 

FIG. 34 illustrates a relationship between major themes 65 FIG. 60 illustrates the manner in which the AttributeDic- 

thal impact aspects of software development and manage- tionaryClient is the facade which delegates to the Atlribute- 

ment; Dictionary; 
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FIG. 61 depicts the use of the containsKeyO method on 
the HashMap to ensure that the value will exist before the 
getQ method is used; 

FIG. 62 illustrates a method that dictates that any 
nullPointerException that is thrown would be caught and 
rethrown as the more user-friendly exception in the attribute 
dictionary pattern environment; 

FIG. 63 illustrates the Get the Attribute Names method in 
the attribute dictionary pattern environment; 

FIG. 64 illustrates a flowchart for a method for managing 
constants in a computer program in accordance with an 
embodiment of the present invention; 

FIG. 65 illustrates a flowchart for a method for providing 
a fixed format stream-based communication system in 
accordance with an embodiment of the present invention; 

FIG. 66 illustrates two systems communicating via a 
stream-based communication and using a common generic 
format to relay the meta-data information; 

FIG. 67 illustrates an example of a Fixed Format message 
associated with the fixed format stream patterns; 

FIG. 68 depicts the complete Fixed Format Stream pattern 
associated with the fixed format stream patterns; 

FIG. 69 illustrates fixed format contracts containing meta- 
data information for translating structured data onto and off 
of a stream; 

FIG. 70 illustrates a Customer object in an object-based 
system streaming itself into a stream, the stream being sent 
to a non -object system, this stream being read and the data 
inserted into a relational database; 

FIG, 71 illustrates a flowchart for a method for delivering 
service via a globally addressable interface in accordance 
with an embodiment of the present invention; 

FIG, 72 depicts a client that is unable to find the services 
provided by a server via a network; 

FIG. 73 illustrates the grouping of services using inter- 
faces; 

FIG. 74 illustrates a customer server publicly announcing 
its interfaces; 

FIG. 75 illustrates a method including the registering and 
then locating of a globally addressable interface; 

FIG. 76 illustrates the present invention using a method 
wherein a globally addressable interface is used to obtain 
data from a server; 

FIG. 77 illustrates a flowchart for a method for affording 
access to a legacy system in accordance to an embodiment 
of the present invention; 

FIG. 78 depicts the communication difficulties associated 
with Legacy Systems attempting to communicate with a 
client via a component integration architecture; 

FIG. 79 illustrates homogenous interfaces from compo- 
nents which rectify the problems with Legacy Systems 
attempting to communicate with a client via a component 
integration architecture; 

FIG. 80 shows how a Legacy Component is integrated 
into a component-based model; 

FIG. 81 illustrates Legacy Wrapper Components of a Pure 
Legacy Wrapper Component including a Legacy Wrapper 
Component, a Component Adapter, a Legacy Integration 
Architecture, a Legacy Adapter, and a Legacy System; 

FIG. 82 illustrates a Hybrid Component type of Legacy 
Wrapper Component; 

FIG. 83 shows an abstract example of the control flow in 
a Legacy Component; 
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FIG. 84 illustrates a flowchart for a method for for 
delivering service via a locally addressable interface in 
accordance with an embodiment of the present invention; 

FIG. 85 illustrates Problems with Globally Addressable 
5 Interfaces in a system including clients and servers with a 
plurality of interfaces; 

FIG. 86 illustrates the manner in which the present 
invention uses a Locally Addressable Interface to hide 
functionality and lessen the load on the Naming or Trading 
10 Service; 

FIG. 87 illustrates the manner in which the present 
invention obtains a Locally Addressable Interface; 

FIG. 88 illustrates the method in which the present 
15 invention registers and then locates a Globally Addressable 
Interface; 

FIG. 89 illustrates the manner in which the present 
invention uses a Globally Addressable Interface to obtain a 
Locally Addressable Interface to a specific Customer Object; 
20 FIG. 90 illustrates a flowchart for a method for commu- 
nicating a null value in accordance with an embodiment of 
the present invention; 

FIG. 91 illustrates the problem associated with sending a 
NULL across many types of middleware; 

FIG. 92 illustrates the manner in which the present 
invention passes a "null" structure across the middleware; 

FIG. 93 depicts conversations with a "null" data structure; 

FIG. 94 depicts conversations with a non-"nuH" data 
30 structure; 

FIG. 95 illustrates a flowchart for a method for transmit- 
ting data from a server to a client via pages in accordance 
with an embodiment of the present invention; 

FIG. 96 depicts the response time for a User Interface to 
35 display a list of customers in a list box; 

FIG. 97 shows a request that returns a large amount of 
data; 

FIG. 98 shows a graphical depiction of a paging commu- 
4Q nication pattern; 

FIG. 99 illustrates a message trace diagram showing the 
interactions between a Client and a Server using Paging 
Communication to satisfy the previously mentioned sce- 
nario; 

45 FIG. 100 illustrates a flowchart for a method for inter- 
facing a naming service and a client with the naming service 
allowing access to a plurality of different sets of services 
from a plurality of globally addressable interfaces in accor- 
dance with an embodiment of the present invention; 

50 FIG. 101 illustrates repeated requests to the Trader Ser- 
vice for the same interfaces; 

FIG. 102 illustrates how a pool can be created that reuses 
GAI proxies; 

FIG. 103 illustrates the implementation of a Refreshable 
55 Proxy Pool; 

FIG. 104 illustrates the class relationships between the 
patterns primary classes; 

FIG. 105 illustrates a flowchart for a method for providing 
60 a self -describing stream-based communication system in 
accordance with an embodiment of the present invention; 

FIG. 106 illustrates two systems communicating via 
Stream-Based Communication and using a shared generic 
format to relay the meta-data information; 
65 FIG. 107 illustrates an object-based system with a fre- 
quently changing object model communicating via Stream- 
Based Communication; 
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FIG. 108 illustrates a stream-based message that contains FIG. 132 illustrates a rule validation interaction diagram; 

both message data and descriptive meta-data; piG. 133 illustrates a flowchart for a method for assigning 

FIG. 109 illustrates the manner in which a message a view to an activity in accordance with an embodiment of 

language defines how to parameterize the meta-data and put the present invention; 

it on the stream; 5 pj G 134 illustrates a manner in which the maintain 

FIG. 110 illustrates a Customer object in an object -based customer activity operation of the present invention 

system streaming itself into a stream, the stream being sent launches its view; 

to a non-object system, this stream being read and the data FIG. 135 illustrates the view configurer launching the 

inserted into a relational database; maintain customer view operation; 

FIG. Ill illustrates a flowchart for a method for providing FIG. 136 illustrates a flowchart for a method for testing 

a stream-based communication system in accordance with successfulness of an operation having pre-conditions and 

an embodiment of the present invention; post-conditions that must be satisfied for the operation to be 

FIG. 112 illustrates how systems of the present invention successful in accordance with an embodiment of the present 

communicate over a communication mechanism that cannot ^ invention; 

inherently convey meta-data information; FIG. 137 illustrates an operation diagram depicting an 

FIG. 113 is an illustration of an object-based system example of pre-conditions and post-conditions; 

communicating with a non-object system using a commu- FIG. 138 illustrates a flowchart for a method for detecting 

nication mechanism that cannot convey meta-data informa- an orphaned server context in accordance with an embodi- 

tion; 20 ment of the present invention; 

FIG, 114 depicts an example of Stream Based Commu- FIG* 139 illustrates a Client 1 that has instantiated A and 

nication with two disparate systems communicating via C, deletes C but fails to delete A; 

stream-based communication; FIG. 140 illustrates a Garbage Collector requesting for 

FIG. 115 is an illustration of a Customer object in an interest in context A; 

object -based system streaming itself into a stream, the 25 FIG. 141 illustrates a Garbage Collect or requesting for 

stream being sent to a non-object system, this stream being interest in context B; 

read and the information is inserted into a relational data- FIG. 142 illustrates a flowchart for a method for creating 

base; a common interface for exception handling in accordance 

FIG. 116 illustrates a flowchart for a method for efficiently 3Q with an embodiment of the present invention; 

retrieving data in accordance with an embodiment of the FIG. 143 illustrates how having many different exception 

present invention; types will cause the exception handling logic to grow; 

FIG. 117 illustrates the manner in which a client requests FIG. 144 illustrates that groupings are not always exclu- 

information from server objects via a network; sive; 

FIG, 118 illustrates the method of the present invention in 35 FIG. 145 illustrates a flowchart for a method for recording 

which a client requests attributes from a server object via a exception handling requirements for maintaining a consis- 

network; tent error handling approach in accordance with an embodi- 

FIG. 119 illustrates the transmitting of all data in a Data meat of the present invention; 

Structure from a client to a server and visa -versa; FIG. 146 illustrates a flowchart for a method for mini- 

FIG. 120 illustrates the method in which a client finds and 40 sizing the amount of changes that need to be made to 

instantiates a Customer Object from a customer component; exception handling logic when new exceptions are added in 

FIG. 121 illustrates a Structure Based Communication accordance with an embodiment of the present invention; 

that builds upon the method of FIG. 120 and depicts the flow FIG - 147 de P lcts a program (i.e., the exception handler of 

of control during Structure Based Communication; the P resent invention) with a few try-catch blocks; 

FIG. 122 shows Five Styles of Client/Server Computing; FIG " 148 de P icts a program (the polymorphic exception 

t-tw- ni -ii . < a u *u • j • handler) with smaller catch blocks; 

FIG. 123 illustrates a flowchart for a method for providing ' An .„ ' 

an activity module in accordance with an embodiment of the . : 149 Urates a flowchart for a method for distnb- 

present invention' ulwg mcomin S requests amongst server components for 

i-T^, ' , , ■ . r . i- optimizing usage of resources in accordance with an 

FIG. 124 illustrates multiple interfaces to an application 50 „ f 7u^ ■ ,_ t - . 

. ... u jt_ u j • j i , j fi embodiment of the present invention 

including a handheld device, a desktop PC, and a telecom- ^ , A ■« 

munications device- illustrates server components receiving service 

1 requests; 

FIG. 125 illustrates an activity entity relationship dia- ™„ i j L 1 j- i_ 

' Mu. 151 illustrates a load balancer mediating the requests 

„ of FIG. ISO; 

FIG. 126 illustrates a roles and responsibilities diagram; FIG. 152 illustrates a flowchart for a method for main- 

F1G. 127 illustrates a typical implementation between a taining a profile throughout nested service invoca . 

user interface and its activity; t j ons on distributed components in accordance with an 

FIG. 128 illustrates a flowchart for a method for stmc- embodiment of the present invention; 

turing validation rules to be applied to a user interface for 6Q F IG. 153 illustrates a component interaction diagram 

maximum maintainability and extensibility in accordance showing an interaction between a number of components in 

with an embodiment of the present invention; a fi nanc j a i system; 

FIG. 129 illustrates widgets with their validation require- FIG. 154 illustrates a user manger/user context relation- 

ments; ship diagram; 

FIG. 130 illustrates a user interface validator association 65 FIG. 155 illustrates a flowchart for a method for trans- 
diagram; la ting an object attribute to and from a database value in 

FIG. 131 illustrates a validation rule class diagram; accordance with an embodiment of the present invention; 
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FIG. 156 illustrates that an attribute cannot be saved 
directly into the persistent store; 

FIG. 157 illustrates the use of an Attribute Converter to 
save an attribute into a database; 

FIG. 158 illustrates a flowchart for a method for control- 5 
ling data in accordance with an embodiment of the present 
invention; 

FIG. 159 illustrates the data retrieval mechanism calls 
being placed directly within the domain object; 3Q 

FIG. 160 shows the interrelationship between a database, 
a persist, and an account; 

FIG. 161 illustrates that the database retrieval mechanism 
is separated from the business object by encapsulating the 
logic within a data handler; is 

FIG. 162 illustrates the TiPersistenceStream and TiMap- 
per of an embodiment of the present invention; 

FIG. 163 illustrates a flowchart for a method for organiz- 
ing data access among a plurality of business entities in 
accordance with an embodiment of the present invention; 20 

FIG. 164 illustrates retrieving data piecemeal; 

FIG. 165 illustrates the manner in which the present 
invention retrieves whole objects; 

FIG. 166 illustrates a flowchart for a method for retrieving 25 
multiple business objects across a network in one access 
operation in accordance with an embodiment of the present 
invention; s 

FIG. 167 illustrates an example of an implementation of 
the Multi-Fetch Object; 30 

FIG. 168 illustrates the Fetching of a Household object 
along with the other related objects using the multi object 
fetch results; 

FIG. 169 is an interaction diagram showing when the 35 
multi object fetch is not used; 

FIG. 170 illustrates a flowchart for a method for imple- 
menting an association of business objects without retriev- 
ing the business objects from a database on which the 
business objects are stored in accordance with an embodi- 40 
ment of the present invention; 

FIG. 171 illustrates a flowchart for a method for mapping 
of retrieved data into objects in accordance with an embodi- 
ment of the present invention; 

FIG. 172 illustrates an Object Identity Cache in accor- 45 
dance with one embodiment of the present invention; 

FIG. 173 illustrates a flowchart for a method for separat- 
ing logic and data access concerns during development of a 
persistent object for insulating development of business 
logic from development of data access routine in accordance 50 
with an embodiment of the present invention; 

FIG. 174 illustrates a flowchart for a method for providing 
a warning upon retrieval of objects that are incomplete in 
accordance with an embodiment of the present invention; 5S 

FIG. 175 illustrates an Entity-Based Data Access System; 

FIG. 176 illustrates a Retrieving Data Piecemeal System; 

FIG. 177 illustrates a Commit and Rollback routine; 

FIG. 178 illustrates Nested Logical Units of Work; 

FIG. 179 illustrates a flowchart for a method for allowing 
a batched request to indicate that it depends on the response 
to another request in accordance with an embodiment of the 
present invention; 

FIG. 180 illustrates a Batching Retrievals and Depen- 65 
dency; 

FIG. 181 illustrates the Dynamically Setting Dependency; 
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FIG. 182 illustrates a flowchart for a method for sending 
a single message to all objects in a logical unit of work in 
accordance with an embodiment of the present invention; 

FIG. 183 illustrates a Hand -crafted Message Forwarding 
scheme; 

FIG. 184 illustrates a Generic Message Forwarding fea- 
ture; 

FIG. 185 illustrates a flowchart for a method for batching 
logical requests for reducing network traffic in accordance 
with an embodiment of the present invention; 

FIG. 186 illustrates the manner in which the present 
invention sends requests independently; 

FIG. 187 illustrates a manner in which the present inven- 
tion registers requests; 

FIG. 188 illustrates a flowchart for a method for sorting 
requests that are being unbatched from a batched message in 
accordance with an embodiment of the present invention; 

FIG. 189 illustrates an Ad Hoc Registration feature; 

FIG. 190 illustrates a manner in which the present inven- 
tion sorts requests by weight; 

FIG. 191 illustrates a flowchart for a method for assigning 
independent copies of business data to concurrent logical 
units of work for helping prevent the logical units of work 
from interfering with each other in accordance with an 
embodiment of the present invention; 

FIG. 192 illustrates the MVC Implementation with Global 
Model; 

FIG. 193 illustrates the Separate Models for Separate 
Business LUWs; 

FIG. 194 illustrates the Canceling of one LUW Indepen- 
dently of Another LUW; and 

FIG. 195 illustrates the Context Copying Protects Context 
Boundaries. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

A preferred embodiment of a system in accordance with 
the present invention is preferably practiced in the context of 
a personal computer such as an IBM compatible personal 
computer, Apple Macintosh computer or UNIX based work- 
station. A representative hardware environment is depicted 
in FIG. 1, which illustrates a typical hardware configuration 
of a workstation in accordance with a preferred embodiment 
having a central processing unit 110, such as a 
microprocessor, and a number of other units interconnected 
via a system bus 112. The workstation shown in FIG. 1 
includes a Random Access Memory (RAM) 114, Read Only 
Memory (ROM) 116, an I/O adapter 118 for connecting 
peripheral devices such as disk storage units 120 to the bus 
112, a user interface adapter 122 for connecting a keyboard 
124, a mouse 126, a speaker 128, a microphone 132, and/or 
other user interface devices such as a touch screen (not 
shown) to the bus 112, communication adapter 134 for 
connecting the workstation to a communication network 
(e.g., a data processing network) and a display adapter 136 
for connecting the bus 112 to a display device 138. The 
workstation typically has resident thereon an operating 
system such as the Microsoft Windows NT or Windows/95 
Operating System (OS), the IBM OS/2 operating system, the 
MAC OS, or UNIX operating system. Those skilled in the 
art will appreciate that the present invention may also be 
implemented on platforms and operating systems other than 
those mentioned. 

A preferred embodiment is written using JAVA, C, and the 
C++ language and utilizes object oriented programming 
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methodology. Object oriented programming (OOP) has 
become increasingly used to develop complex applications. 
As OOP moves toward the mainstream of software design 
and development, various software solutions require adap- 
tation to make use of the benefits of OOP. A need exists for 
these principles of OOP to be applied to a messaging 
interface of an electronic messaging system such that a set 
of OOP classes and objects for the messaging interface can 
be provided. OOP is a process of developing computer 
software using objects, including the steps of analyzing the 
problem, designing the system, and constructing the pro- 
gram. An object is a software package that contains both 
data and a collection of related structures and procedures. 
Since it contains both data and a collection of structures and 
procedures, it can be visualized as a self-sufficient compo- 
nent that does not require other additional structures, pro- 
cedures or data to perform its specific task. OOP, therefore, 
views a computer program as a collection of largely autono- 
mous components, called objects, each of which is respon- 
sible for a specific task. This concept of packaging data, 
structures, and procedures together in one component or 
module is called encapsulation. 

In general, OOP components are reusable software mod- 
ules which present an interface that conforms to an object 
model and which are accessed at run-time is through a 
component integration architecture. A component integra- 
tion architecture is a sel of architecture mechanisms which 
allow software modules in different process spaces to utilize 
each others capabilities or functions. This is generally done 
by assuming a common component object model on which 
to build the architecture. It is worthwhile to differentiate 
between an object and a class of objects at this point. An 
object is a single instance of the class of objects, which is 
often just called a class. A class of objects can be viewed as 
a blueprint, from which many objects can be formed. 

OOP allows the programmer to create an object that is a 
part of another object. For example, the object representing 
a piston engine is said to have a composition-relationship 
with the object representing a piston. In reality, a piston 
engine comprises a piston, valves and many other compo- 
nents; the fact that a piston is an element of a piston engine 
can be logically and semantically represented in OOP by two 
objects. OOP also allows creation of an object that "depends 
from" another object. If there are two objects, one repre- 
senting a piston engine and the other representing a piston 
engine wherein the piston is made of ceramic, then the 
relationship between the two objects is not that of compo- 
sition. A ceramic piston engine does not make up a piston 
engine. Rather it is merely one kind of piston engine that has 
one more limitation than the piston engine; its piston is made 
of ceramic. In this case, the object representing the ceramic 
piston engine is called a derived object, and it inherits all of 
the aspects of the object representing the piston engine and 
adds further limitation or detail to it. The object representing 
the ceramic piston engine "depends from" the object repre- 
senting the piston engine. The relationship between these 
objects is called inheritance. 

When the object or class representing the ceramic piston 
engine inherits all of the aspects of the objects representing 
the piston engine, it inherits the thermal characteristics of a 
standard piston defined in the piston engine class. However, 
the ceramic piston engine object overrides these ceramic 
specific thermal characteristics, which are typically different 
from those associated with a metal piston. It skips over the 
original and uses new functions related to ceramic pistons. 
Different kinds of piston engines have different 
characteristics, but may have the same underlying functions 
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associated with it (e.g., how many pistons in the engine, 
ignition sequences, lubrication, etc.). To access each of these 
functions in any piston engine object, a programmer would 
call the same functions with the same names, but each type 

5 of piston engine may have different/overriding implemen- 
tations of functions behind the same name. This ability to 
hide different implementations of a function behind the same 
name is called polymorphism and it greatly simplifies com- 
munication among objects. 

30 With the concepts of composition-relationship, 
encapsulation, inheritance and polymorphism, an object can 
represent just about anything in the real world. In fact, one's 
logical perception of the reality is the only limit on deter- 
mining the kinds of things that can become objects in 

15 object-oriented software. Some typical categories are as 
follows: 

Objects can represent physical objects, such as automo- 
biles in a traffic-flow simulation, electrical components 
in a circuit-design program, countries in an economics 
20 model, or aircraft in an air-traffic-control system. 

Objects can represent elements of the computer-user 
environment such as windows, menus or graphics 
objects. 

An object can represent an inventory, such as a personnel 
25 file or a table of the latitudes and longitudes of cities. 
An object can represent user-defined data types such as 

time, angles, and complex numbers, or points on the 

plane. 

With this enormous capability of an object to represent 
30 just about any logically separable matters, OOP allows the 
software developer to design and implement a computer 
program that is a model of some aspects of reality, whether 
that reality is a physical entity, a process, a system, or a 
composition of matter. Since the object can represent 
35 anything, the software developer can create an object which 
can be used as a component in a larger software project in 
the future. 

If 90% of a new OOP software program consists of 
proven, existing components made from preexisting reus- 

40 able objects, then only the remaining 10% of the new 
software project has to be written and tested from scratch. 
Since 90% already came from an inventory of extensively 
tested reusable objects, the potential domain from which an 
error could originate is 10% of the program. As a result, 

45 OOP enables software developers to build objects out of 
other, previously built objects. 

This process closely resembles complex machinery being 
built out of assemblies and sub-assemblies. OOP 
technology, therefore, makes software engineering more like 

50 hardware engineering in that software is built from existing 
components, which are available to the developer as objects. 
All this adds up to an improved quality of the software as 
well as an increased speed of its development. 

Programming languages are beginning to fully support the 

55 OOP principles, such as encapsulation, inheritance, 
polymorphism, and composition -relationship. With the 
advent of the C++ language, many commercial software 
developers have embraced OOP. C++ is an OOP language 
that offers a fast, machine-executable code. Furthermore, 

60 C++ is suitable for both commercial-application and 
systems-programming projects. For now, C++ appears to be 
the most popular choice among many OOP programmers, 
but there is a host of other OOP languages, such as 
Smalltalk, Common Lisp Object System (CLOS), and Eiffel. 

65 Additionally, OOP capabilities are being added to more 
traditional popular computer programming languages such 
as Pascal. 
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The benefits of object classes can be summarized, as control. This was appropriate for printing out paychecks, 

follows: calculating a mathematical table, or solving other problems 

Objects and their corresponding classes break down com- ^Ih a program that executed in just one way. 

plex programming problems into many smaller, sim- ^ development of graphical user interfaces began to 

pier problems. 5 turn this procedural programming arrangement inside out. 

Encapsulation enforces dala abstraction through the orga- T" 686 ["'"faces allow the user rather than program logic to 

nization of data into small, independent objects that can dnv f e lhe P r °8 r J am and declde wh , en certaln acl ' ons shou,d be 

communicate with each other. Encapsulation protects Pfrformed. Today, most personal computer software accom- 

the data in an object from accidental damage, but P^hes this by means of an event loop which monitors the 

allows other objects to interact with that data by calling 10 m °" se J keyboard, and other sources of external events and 

the object's member functions and structures. calls tr« appropriate parts of the programmer scode accord- 

P , . j • i_ i m_i * j 10 actions that the user performs. The programmer no 

Subclassing and inheritance make it possible to extend . . j ■ . » i 

j j. r l .^l - i ■ j r longer determines the order in which events occur. Instead, 

and modify objects through deriving new kinds of & . . , , . 4 4 , „ « 

. jji m i— t ■ ,l a program is divided into separate pieces that are called at 

obiects from the standard classes available in the sys- j- . . i • • j- 4 L1 ^ ,. 

4 r™. „ . , ... , , f 15 unpredictable times and m an unpredictable order. By rehn- 

tem. Thus, new capabilities are created without having f,. 4 , . if _. 4 r tl _ , . J 

t t t f f u quishing control in this way to users, the developer creates 

to start iroro sera ten. . i , ■ ■ ■ „ * T .11 - i- 

, . „ , a program that is much easier to use. Nevertheless, indi- 

Polymorphism and multiple inheritance make rt possible vidual ieces of tfae wriUen b the devel still 

for different programmers to mix and match character- caU Ubraries provided by lhe operating system t0 accomplish 

istics of many different classes and create specialized 2Q ceftain taskgj and ^ ogrammer must stil! deter mine the 

objects that can stdl work with related objects in flf)W of comro , each pfece after ^ ca , led by ^ 

predictable ways. evem loQp y^pplication code still "sits on top of the system. 

Class hierarchies and containment hierarchies provide a Even event loop programs require programmers to write 

flexible mechanism for modeling real-world objects a lot of code thal should not need t0 be writlen separatel y for 

and the relationships among them. 25 every application. The concept of an application framework 

Libraries of reusable classes are useful in many situations, carries the event loop concept further. Instead of dealing 

but they also have some limitations. For example: ^th all the nuts and bolts of constructing basic menus, 

Complexity. In a complex system, the class hierarchies for windows, and dialog boxes and then making these things all 

related classes can become extremely confusing, with work together, programmers using application frameworks 

many dozens or even hundreds of classes. 30 start with working application code and basic user interface 

Row of control. A program written with the aid of class elements in place. Subsequently, they build from there by 

libraries is still responsible for the flow of control (i.e., replacing some of the generic capabilities of the framework 

it must control the interactions among all the objects with the specific capabilities of the intended application, 

created from a particular library). The programmer has Application frameworks reduce the total amount of code 

to decide which functions to call at what times for 35 that a programmer has to write from scratch. However, 

which kinds of objects. because the framework is really a generic application that 

Duplication of effort. Although class libraries allow pro- displays windows, supports copy and paste, and so on, the 

grammers to use and reuse many small pieces of code, programmer can also relinquish control to a greater degree 

each programmer puts those pieces together in a dif- than event loop programs permit. The framework code takes 

ferent way. Two different programmers can use the 40 care of almost all event handling and flow of control, and the 

same set of class libraries to write two programs that do programmer's code is called only when the framework 

exactly the same thing but whose internal structure needs it (e.g., to create or manipulate a proprietary data 

(i.e., design) may be quite different, depending on structure). 

hundreds of small decisions each programmer makes A programmer writing a framework program not only 

along the way. Inevitably, similar pieces of code end up 45 relinquishes control to the user (as is also true for event loop 

doing similar things in slightly different ways and do programs), but also relinquishes the detailed flow of control 

not work as well together as they should. within the program to the framework. This approach allows 

Class libraries are very flexible. As programs grow more the creation of more complex systems that work together in 

complex, more programmers are forced to reinvent basic interesting ways, as opposed to isolated programs, having 

solutions to basic problems over and over again. A relatively 50 custom code, being created over and over again for similar 

new extension of the class library concept is to have a problems. 

framework of class libraries. This framework is more com- Thus, as is explained above, a framework basically is a 

plex and consists of significant collections of collaborating collection of cooperating classes that make up a reusable 

classes that capture both the small scale patterns and major design solution for a given problem domain. It typically 

mechanisms that implement the common requirements and 55 includes objects that provide default behavior (e.g., for 

design in a specific application domain. They were first menus and windows), and programmers use it by inheriting 

developed to free application programmers from the chores some of that default behavior and overriding other behavior 

involved in displaying menus, windows, dialog boxes, and so that the framework calls application code at the appro - 

other standard user interface elements for personal comput- priale limes. 

ers. 60 There are three main differences between frameworks and 

Frameworks also represent a change in the way program- class libraries: 

mers think about the interaction between the code they write Behavior versus protocol. Class libraries are essentially 

and code written by others. In the early days of procedural collections of behaviors that you can call when you 

programming, the programmer called libraries provided by want those individual behaviors in your program. A 

the operating system to perform certain tasks, but basically 65 framework, on the other hand, provides not only behav- 

the program executed down the page from start to finish, and ior but also the protocol or set of rules that govern the 

the programmer was solely responsible for the flow of ways in which behaviors can be combined, including 
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rules for what a programmer is supposed to provide 
versus what the framework provides. 
Call versus override. With a class library, the code the 
programmer instantiates objects and calls their member 
functions. It's possible to instantiate and call objects in 
the same way with a framework (i.e., to treat the 
framework as a class library), but to take full advantage 
of a framework's reusable design, a programmer typi- 
cally writes code that overrides and is called by the 
framework. The framework manages the flow of con- 
trol among its objects. Writing a program involves 
dividing responsibilities among the various pieces of 
software that are called by the framework rather than 
specifying how the different pieces should work 
together. 

Implementation versus design. With class libraries, pro- 
grammers reuse only implementations, whereas with 
frameworks, they reuse design. A framework embodies 
the way a family of related programs or pieces of 
software work. It represents a generic design solution 
that can be adapted to a variety of specific problems in 
a given domain. For example, a single framework can 
embody the way a user interface works, even though 
two different user interfaces created with the same 
framework might solve quite different interface prob- 
lems. 

Thus, through the development of frameworks for solu- 
tions to various problems and programming tasks, signifi- 
cant reductions in the design and development effort for 
software can be achieved. A preferred embodiment of the 
invention utilizes HyperText Markup Language (HTML) to 
implement documents on the Internet together with a 
general-purpose secure communication protocol for a trans- 
port medium between the client and the Newco. HTTP or 
other protocols could be readily substituted for HTML 
without undue experimentation. Information on these prod- 
ucts is available in T. Beraers-Lee, D. Connoly, "RFC 1866: 
Hypertext Markup Language — 2.0" (November 1995); and 
R. Fielding, H, Frystyk, T Bemers-Lee, J. Gettys and J. C. 
Mogul, "Hypertext Transfer Protocol— HTTP/1.1: HTTP 
Working Group Internet Draft" (May 2, 1996). HTML is a 
simple data format used to create hypertext documents that 
are portable from one platform to another. HTML docu- 
ments are SGML documents with generic semantics that are 
appropriate for representing information from a wide range 
of domains. HTML has been in use by the World-Wide Web 
global information initiative since 1990. HTML is an appli- 
cation of ISO Standard 8879; 1986 Information Processing 
Text and Office Systems; Standard Generalized Markup 
Language (SGML). 

To date, Web development tools have been limited in their 
ability to create dynamic Web applications which span from 
client to server and interoperate with existing computing 
resources. Until recently, HTML has been the dominant 
technology used in development of Web-based solutions. 
However, HTML has proven to be inadequate in the fol- 
lowing areas: 

Poor performance; 

Restricted user interface capabilities; 
Can only produce static Web pages; 
Lack of interoperability with existing applications and 

data; and 
Inability to scale. 

Sun Microsystem's Java language solves many of the 
client-side problems by: 

Improving performance on the client side; 
Enabling the creation of dynamic, real-time Web appli- 
cations; and 
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Providing the ability to create a wide variety of user 

interface components. 
With Java, developers can create robust User Interface 
(UI) components. Custom "widgets" (e.g., real-time stock 

5 tickers, animated icons, etc.) can be created, and client-side 
performance is improved. Unlike HTML, Java supports the 
notion of client-side validation, offloading appropriate pro- 
cessing onto the client for improved performance. Dynamic, 
real-time Web pages can be created. Using the above - 

10 mentioned custom UI components, dynamic Web pages can 
also be created. 

Sun's Java language has emerged as an industry- 
recognized language for "programming the Internet." Sun 

15 defines Java as: "a simple, object-oriented, distributed, 
interpreted, robust, secure, architecture-neutral, portable, 
high-performance, multithreaded, dynamic, buzzword- 
compliant, general-purpose programming language. Java 
supports programming for the Internet in the form of 

20 platform-independent Java applets/' Java applets are small, 
specialized applications that comply with Sun's Java Appli- 
cation Programming Interface (API) allowing developers to 
add "interactive content" to Web documents (e.g., simple 
animations, page adornments, basic games, etc.). Applets 

25 execute within a Java-compatible browser (e.g., Netscape 
Navigator) by copying code from the server to client. From 
a language standpoint, Java's core feature set is based on 
C++. Sun's Java literature states that Java is basically, "C++ 
with extensions from Objective C for more dynamic method 

30 resolution." 

Another technology that provides similar function to 
JAVA is provided by Microsoft and ActiveX Technologies, 
to give developers and Web designers wherewithal to build 
dynamic content for the Internet and personal computers. 

35 ActiveX includes tools for developing animation, 3-D vir- 
tual reality, video and other multimedia content. The tools 
use Internet standards, work on multiple platforms, and are 
being supported by over 100 companies. The group's build- 
ing blocks are called ActiveX Controls, small, fast compo- 

40 nents that enable developers to embed parts of software in 
hypertext markup language (HTML) pages. ActiveX Con- 
trols work with a variety of programming languages includ- 
ing Microsoft Visual C++, Borland Delphi, Microsoft Visual 
Basic programming system and, in the future, Microsoft's 

45 development tool for Java, code named "Jakarta." ActiveX 
Technologies also includes ActiveX Server Framework, 
allowing developers to create server applications. One of 
ordinary skill in the art readily recognizes that ActiveX 
could be substituted for JAVA without undue experimenta- 

50 tion to practice the invention. 

Overview 

Architecture Basics 
Architecture Overview 
What is architecture? 

Architecture — whether the word is applied to work with 
a city skyline or an information system — is both about 

60 designing something and about making, building, or con- 
structing something. An architect is literally a "master 
builder" — from the Greek words archi (primary or master) 
and tekton (builder or carpenter). In good Greek fashion, 
however, it would be unthinkable for something to be built 

65 without a sound theoretical basis. So architecture involves 
theory, but there is nothing merely theoretical about it. 
Conversely, architecture is also eminently practical, but 
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there is nothing merely practical about it. Ideas about form 
and structure lie behind architecture. Ultimately one must let 
go of a mindset that tries to separate the designing from the 
making; they exist together as a whole, and to extract one 
without the other is to kill the whole. 

Architecture also is an engineering discipline. It creates 
and also depends on a structured manner to analyze and 
design whatever is to be built. Like all living disciplines, 
architecture continues to grow and evolve. Engineering 
discoveries move the field forward. Certain design and 
engineering principles clearly show themselves to be suc- 
cessful in practice, and these then become repeatable com- 
ponents of additional work. The ability to continue to master 
each component, as well as the interrelations among 
components, is a distinguishing characteristic of architec- 
ture. 

So architecture is about designing and building something 
from a set of basic components, and also about the interre- 
lations among the components. And it is a discipline 
whereby all these things come together — materials, space, 
people — to bring something into being that was not there 
before. 

Although building architects have not always been 
pleased about it, architectural concepts have influenced 
other kinds of "building" projects for some time. Over the 
past twenty years, developers of information systems, for 
example, have used concepts from the field of architecture 
not only to describe their work but to execute it, as well. 

The use of architectural thinking implies that the work is 
about creating certain kinds of structures that can be engi- 
neered or at least influenced, and that the work can be 
organized and performed in a structured, systematic manner. 
Moreover, use of architectural concepts implies that there is 
something repeatable about the work: architects can create a 
structure, then use components of that structure again in the 
future when they come across a similar situation. 

An architectural paradigm should not be lightly used. It 
makes demands. To use architectural concepts implies that 
clients are ready to do so — that is, that the field is sufficiently 
mature in its work to see patterns and to organize future 
work according to those patterns. 

Finally, architecture must be understood as a process 200, 
not just a thing. This process can be described at a very high 
level using FIG. 2. 

Step 1: Analyze 202. The architect must begin by listening 
to and researching the needs of the client. What is the 
function of the building? What is its environment? 
What are the limitations set by budget and use? 
Step 2: Design 204. This is a blueprint stage. The architect 
creates one or several designs showing the layout of the 
structure, how different spaces fit together, how every- 
thing looks from different views, what materials are to 
be used, and so forth. 
Step 3: Model & Test 206. Not every architectural project 
has this step, but in many cases, the architect will create 
a scale model/prototype of the finished product, allow- 
ing the client a clearer sense of what the ultimate 
solution will look like. A model is a kind of test stage, 
allowing everyone to test the design in a near- real-life 
setting. 

Step 4: Build 208. This is the actual construction of the 
building, in general accord with the blueprints and 
prototype. 

Step 5: Operate and Evolve 210. The building is to be 
lived in and used, of course, and so an important step 
is to ensure that the finished product is tended and 
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operated effectively. Architects themselves may not be 
involved in the operation of their building, but they 
certainly would be involved in future expansions or 
evolutions of the building. Stewart Brand's recent text, 
5 How Buildings Learn, argues that effective architecture 
takes into account the fact that buildings "learn": as 
people live and work in them over time, those people 
will seek to alter the building in subtle, or not so subtle, 
ways. 

Also, when architects design a building, they have in their 
heads a primary conceptual framework for all the compo- 
nents that go into that building: the plumbing, the electric, 
the sewers, stairs/elevators, framing structure, and so forth. 
The tacit step for an architect is, "Based on my knowledge 
of the generic components that go into a building, how will 
15 these components fit together in this particular building? 
Which of these components will require special attention 
because of the functional demands of the building?" 
Oxford English Dictionary Definition: 
The conceptual structure and overall logical organization 
20 of a computer or computer-based system from the point 
of view of its use or design; a particular realization of 
this. 

Gartner Group Definition: 
The manner or structure in which hardware or software is 
25 constructed. Defines how a system or program is 
structured, how various components and parts interact, 
as well as what protocols and interfaces are used for 
communication and cooperation between modules and 
components which make up the system. 
30 Gartner Group sets forth seven general characteristics of 
successful architectures. 

Delimitation of the problem to be addressed 
Decomposition of the solution to components with clearly 
assigned responsibilities. 
35 Definition of interfaces, formats, and protocols to be used 
between the components. These should be sufficiently 
clear and robust in order to permit asynchronous devel- 
opment and ongoing re-implementation of the compo- 
nents. 

40 Adequate documentation to permit compliance by imple- 
mentors 

An auditing mechanism that exercises the specified inter- 
faces to verify that specified inputs to components yield 
specified results 
45 An extendibility mechanism to enable response to chang- 
ing requirements and technologies 
Policies, practices, and organizational structures that 

facilitate adoption of the architecture 
What types of architectures are discussed in the following 
50 description? 

Standard Architecture Framework (SAF) 300 provides 
access to the user's thought leadership and architecture 
frameworks for Execution, Development and Operations 
environments 302,304,306. For a more detailed discussion 
55 on these architectures, please see Standard Architecture 
Summaries (below), FIG. 3 shows the dependencies of the 
three architecture frameworks and is described in more 
detail in the Delivery Vehicle Overview (below). 

The following lists are starting points for considering the 
60 range of components and activities that must be covered by 
each architectural view of the system. They are not a 
definitions of the environments. 
Standard Architecture Summaries 
Execution Architecture 302 
65 The execution architecture is a unified collection of 
run-time technology services, control structures, and sup- 
porting infrastructure upon which application software runs. 
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It includes components such as: 
Application messaging 
Batch processing architecture 
Middleware 
Reporting 
Error handling 
On-line architecture 
Security 
Code/decode 
Data access methods 
Integrated help 
File transfer capabilities 
Directory services 
Load balancing 
Workflow services 
State management 

"Special" requirements (e.g., workflow, telephony, 20 
groupware) 
Development Architecture Framework 304 

The Development Architecture Framework (DAF) is a 
unified collection of technology services, tools, techniques, 
and standards for constructing and maintaining application 
software. 

It includes components such as: 

Design/documentation tools 

Information repository 

Project Management tools 

Program Shells 

GUI Window painter 

Prototyping tools 

Programmer APIs 

Testing tools 

Source code control/build process 
Performance test tools 
Productivity tools 
Design tools 
Compiler/debugger 
Editor 

Refer to the Development Architecture Framework appli- 
cation (referenced above) for more information. 
Operations Architecture 306 

A unified collection of technology services, tools, stan- 
dards and controls required to keep a business application 
production or development environment operating at the 
designed service level. It differs from an execution archi- 
tecture in that its primary users are system administrators 
and production support personnel. 

It includes components such as: 

Job scheduler 

Software distribution 

Error monitor 

Data backup and restore 

Help desk 

Security administration 
High-Availability 
Hardware management 
Performance monitors 
Startup/shutdown procedures 
Report management tool 
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Disaster Recovery 

Network Monitoring Tools 

Cross Platform Management Tools 
Considerations — All Environments 

To ensure that you are asking the right questions about the 
technology architecture, you must refer to the Architecture 
Checklist (available from the Content Finder). Questions 
will include: 

For all technology components, have the following char- 
acteristics been addressed: 

Performance according to specifications? 
Reliability of operation? 
Ease of operation? 
Maintenance requirements? 

Ability to interface with other components, particularly 

those from other vendors? 
Delivery schedule to provide adequate pre-conversion 

testing? 
Backup procedures? 

Vendor reliability and financial stability? 

Future proofing against business change? 

Have the versions of system software been live at another 
site for at least six to twelve months? 

This time frame varies by product. Have reference sites 
been verified? 
What is a framework? 

It is a major challenge to design the complex infrastruc- 
ture that is needed to satisfy the requirements of today's 
distributed, mission-critical applications. As such, it is help- 
ful to have an inventory of the components that may be 
required for the design, build, installation and operation of 
systems. It is also helpful to have an understanding of how 
the components fit together conceptually. 

A Framework should be thought of as a conceptual 
structure used to frame the work about to be done. It should 
be used as a thought trigger or as a completeness check. You 
cannot build from a framework directly but instead should 
use it as a starting point for understanding and designing. 

Frameworks are used to help practitioners understand 
what components may be required and how the components 
fit together. Based on the inventory of components and the 
description of their relationships, practitioners will select the 
necessary components for their design. An architect extracts 
components from one or more Frameworks to meet a 
specific set of user or application requirements. Once an 
architecture has been implemented it is often referred to as 
an architecture or an infrastructure. 

The scope of what a framework addresses can vary 
widely. One framework, for instance, may outline the com- 
ponents for a technical infrastructure in its entirety whereas 
another framework may focus explicitly on the network. A 
thorough understanding of a framework's scope is crucial to 
its use during the design phase of a project. 

It is also important to understand whether the framework 
is vendor specific in nature (proprietary) or whether it is 
available for use by a large number of vendors (open). 
Why is architecture important? 

One has seen the benefits of an architectural approach to 
information systems development: better productivity and 
less reinvention of the wheel. An architecture provides a 
completeness check, ensuring that all relevant components 
of a possible solution have been considered. It ensures 
consistent, reliable, high-quality applications. It gives 
everyone — the developers and their clients — a common 
framework and common language with which to talk about 
the work. 
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Perhaps most important, it allows developers to leverage 
successful solutions when performing additional work. 
Architecture involves repeat able concepts, and so it reduces 
the time and cost by which a solution is delivered. 

Some of the specific technical benefits of a good archi- 
tecture are: 
Simplified Application Development 

Provides common set of application services. Removes 
application programmers from the complexities of 
the underlying technology and development tools, 
allowing less experienced developers to be more 
productive 
Quality 

Usually more experienced developers implement the 
often complex technical components in an architec- 
ture. These components are then reused, avoiding 
duplicated complex logic in the applications. Itera- 
tions during design, implementation and testing 
often result in refinement and improvement of the 
architecture components. All users of these compo- 
nents benefit from such improvements, reducing the 
risk of failure and ensuring better overall quality in 
the final application. 
Integration 

An architecture often ties together disparate software, 
platforms and protocols into one comprehensive 
framework. 
Extensibility 

The architecture is established by experienced person- 
nel who can predict with some confidence whether a 
given architecture will fulfill current and future 
requirements. Code extensions are easily integrated. 
A well-balanced architecture consists of the "right" 
components, where the components are tied together 
by simple interrelationships, since complex relation- 
ships increase the architecture's complexity faster 
than modularization can reduce it. 

Location Transparency 

Divorces application from the details of resource loca- 
tion. This is however not always true or required. For 
performance reasons designers and developers still 
often need to be aware of process and data locations. 

Horizontal Scaling 
Assist in optimal utilization of existing infrastructure 
resulting in increased application performance and 
stability 

Isolation 

An architecture can be used to isolate the applications 
from particular products. This ensures that products 
can more easily be replaced later. This characteristic 
can be important if there is risk associated with a 
product's or product vendor's future, or the rate of 
change in a particular technology area is particularly 
high. An evident example is looking back at changes 
in past user interface standards. Applications that did 
not separate user interface logic from business logic, 
had to be completely rewritten to take advantage of 
new user interfaces, such as MS Windows and more 
recently Web browsers. 
Portability 

Increases portability and reusability within and across 
different platforms or protocols. 
The use of architecture frameworks during analysis and 
design can reduce the risks of an IT solution. It should 
improve development productivity through reuse, as well as 
the IT solution's reliability and maintainability. 



One key challenge for today's IT managers is the need for 
change. Architectures provide a basic framework for major 
change initiatives. Clients* core business is performed by 
strategic applications that will most likely require frequent 
5 and rapid development to handle changes in technology 
capability and business requirements. A properly defined 
and intelligently developed architecture delivers an infra- 
structure on which clients can build and enhance applica- 
tions that support their current and future business needs. 
10 This is how one helps clients to manage change, 

A key benefit of an architecture is that it divides and 
conquers complexity. Simple applications benefit less from 
architecture than complex ones do; fewer decisions are 
needed in these cases, and fewer people need to know about 
them. During maintenance, a poorly architected small appli- 
cation is tolerable because it is still relatively easy to locate 
a fault and to anticipate the side effects of correcting it. 
Conversely, complex applications are more difficult to 
understand and to modify. Complexity is reduced by sub- 
dividing the application in layers and components, each 
layer having a specific functionality. The layers are strongly 
cohesive and decoupled: A given layer does not need to 
know the internals of any other layer. 

The following quote from a recent study of Large Com- 
plex Systems (LCS) stress the importance of a stable archi- 
tectures in large systems: 
Successful delivery of an LCS solution depends on the 
early definition and use of common data applications 
and technology architecture. 

There is a high failure rate when the architecture is not 
defined, stabilized, and delivered early in an LCS 
effort. 

All significant LCS efforts involved the use of common or 
shared architectures. A successful effort, however, 
depended on early definition and delivery of a stable 
common architecture. 

Significant changes to the data, application, or technol- 
ogy architectures bad severe negative effects on the 
timeliness of project deliverables, and on the reli- 
ability of what was delivered. 
PROJECT! and PROJECT2, for example, experienced 
unusual circumstances. While the client evaluated 
whether to proceed, one defines and designs the archi- 
tecture. As a result, the teams had nine months to 
define, design, and begin implementation of required 
data, applications, and development architectures. 
Although in each case these architectures continued to 
evolve with business and technology needs, they 
remained largely consistent with the initial design. This 
consistency proved to be essential to the timely deliv- 
ery of the applications. 
At PROJECT3 and PROJECT4, on the other hand, the 
architectures went through major evolutions as the 
developers created the applications. The overall result 
was that those efforts experienced delays relative to 
plan. 

Although it is not realistic for every project to have nine 
months to define required architectures, it does suggest 
that early focus on definition and design of the archi- 
tectural components is essential. 
The risk of failure is greatly increased if essential archi- 
tectures are being defined or changed significantly in 
parallel with application development. 
What are the benefits of an architecture? 

The benefits derived from a technology architecture may 
allow a user to be in the forefront of the development of 
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many leading edge business solutions. The investment in a Architecture Generation 

reliable and flexible architecture can result in one or more of An architecture generation is a broad classification 

the following: scheme for placing technology components within a tecb- 

Preservation of investments in applications and technol- nolo Sy e . ra - Vehicles are Physically implemented 

ogy by isolating each from changes in the other (e.g. * ° n a dstmct arch.tecture generation. Examples of architec. 

upgrades in hardware or third-plrty software do not ture , ? e ° erat '° ns >° clud * host-based, client-server and net- 

. ° r * \ centric. 

impact applications). Note . Defining a clear Une between what faUs under the 

Leveraging scarce technical skills (e.g. the need for client/server and a Netcentric technology generation is dif- 

people with detailed skills in a specific communications ficult; typically different people tend to have different opin- 

protocol or aspects of SQL). ions. Technologically, the Netcentric generation may be an 

Enhancements in productivity, flexibility and maintain- evolution of the client/server generation. In the context of 

ability because common and often complex and error- the Delivery Vehicles, the technology generation discussion 

prone components (e.g. error handling or cross- mav be inteilded to be a lo gi cal discussion that aims to 

platform communications) are created within the „ highlight the new business capabilities enabled by new 

architecture, and then reused by all applications. 5 technologies. So for example there could be a PowerBuilder 

. , ,. *■%* * . application executing from a Web Browser using a plug-in. 

Increases in the predictability of apphcation performance whether this is called a client/server or Netcentric applica- 

because the run-time behavior of common components tion ^ up t0 the reader preS enting technology archi- 

is familiar and consistent. tecture information to clients, focus on the business capa- 

Serves as a construction blueprint and discussion agenda 20 bilities that are offered by technologies rather than just on 

and ensures consistency across systems. This can have definitions for what is client/server or what is Netcentric 

a big impact on the operability and maintenance of the technology, 

delivered applications. Delivery Vehicle Matrix 

What is an architect'' FIG. 4 illustrates a delivery vehicle matrix 400. One way 

Architects must have deep understanding of a project, 25 ° f l«*mg at » Delivery Vehicle is therefore as an intersec- 

business and/or technical environment. Architects are ^ n °i? tec hnolo g y generation 402 and application style 

involved across business integration projects, managing 404 * ^ 1S the Presentation method currently adopted for 

their complexities and intricacies. ^e^hidJcubc 

How advanced should an architect be? VT"?* r l ° %/ u^i enn n * .a • c 
. . A t_ j i_ j ■ • j • i . m The Delivery Vehicle Cube 500, illustrated in FIG. 5, 
It is easy to go overboard when designing and implement- JU , „%. ,,„ . 4 r , , ^ . . T 
* u i ^ „ r . L ,j represents the full picture of what a Delivery Vehicle is. In 
ing a technology architecture. Ideally the architecture should f,... * A r *• o* i j .i_ t- u i 
, & iL . j c . . , i addition to the Application Styles and the Technology gen- 
be a thin, well-denned layer that ensures development t . . . A l « r «• 

... o •, _c . erations it introduces a distinction between Execution, 

productivity, maintenance flexibility, performance and sta- Developraent and Operations Environments 502,504,506. 

\\ , , T , . « The cube has the following dimensions, or cube "faces: 

A key issue is maintainability and operability. Keep in J0 . ~ iL , „ , ^ - - , , 

mind that others may have to understand the rationale , 0a h tb , e boUom left t face ° f the "* lhe core 

... . ; , . . . , . t . technology components and services 508 that are com - 

behind the architecture design in order to correctly maintain n *, ... 

• t o j mon across a n delivery vehicles. 

• , , L « j These core services may be implemented using one or 

Architecture logic can quickly become very abstract and i r .u T u i ^ , , 

• « . 4 . . u J , if i ■«. A 40 several of the Technology Generations; currently Host, 

hard to maintain by others than those who built it. A r-i™./c M ,— k^,, ■ . , • v . . 

, lt . . JL Client/Server or Netcentric. Most major enterprises have 

carefully designed architecture can quickly be destroyed by , t t . * A . . . . . . . . . 

7 & ,.i . i . . legacy systems that include both host based and distributed 

maintenance personnel that do not understand how it was .. t . KT , # . i- 

, , , r , , , client/server applications. Netcentric applications may 

designed and developed. ■ * * 

,, & , r t . ,. , . , extend the mix of system technologies. 

You should make your architecture as light- weight as , r / r L . , 

, , , , . lU . . ®, , . . -. 45 2. On the top left of the cube are the technology compo- 

possible only addressmg the requirements that drive it. 4 .-n., . . . ,. , , 

a *i « • t , » a -u-r. j jj V ii i f nents 510 that are required to support a distinct delivery 

Avoid nice to have flexibility and additional levels of ... M *^ J 

vehicle 

abstractions that are intellectually interesting but not strictly ™ A t , lL . . . ... , 

. , ' to J These components extend the technology architecture with 

^ rt services that are specific for each distinct delivery vehicle. 

Delivery Vehicle Overview jo Soffle of the componente may extend ^ of the core 

A Delivery Vehicle is an integrated collection of technol- services 

ogy services that supports an application style, implemented 3 Qn ^ ^ face Qf ^ ^ ^ {h& ^ environments 

on a distinct architecture generation. each deliyery vehic]e wil , affect: execution> deve i op . 

Apphcation Style menl and operat i ons 502,504,506. 

An application style defines a unique class of processing S5 Both the core services and the delivery vehicle extensions 

type, which is used by applications, and thus end-users. require support in all three environments. The cube illus- 

Delivery Vehicle Reference set of Application Styles include trates that different delivery vehicles may require different 

batch, on-line transaction processing, collaboration, data extensions to a core development or operations 

warehouse, knowledge management and integration. environment, not just the execution architecture. A mission- 

The Application Style is the primary dimension of a 60 critical high-volume transaction delivery vehicle may 

Delivery Vehicle, and most people use the terms Application require special performance tuning tools in the development 

Style and Delivery Vehicle to mean the same thing. architecture, as well as real-time monitoring tools in the 

A key goal with a delivery vehicle is that it can be reused operations architecture, 

across many applications. It is still part of the Technology Also different technology generations may require special 

Architecture, not involving application specific logic. An 65 services in all three environments. When working in a 

Application Architecture on the other hand, will be specific multi-platform environment, there may be duplicated ser- 

for a particular application. vices across platforms. This usually complicates 
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development, operations and execution architectures and 
may require special focus on providing an integration archi- 
tecture. 

The following figure illustrates the relationship between 
the three environments and the overall business system: 5 

Typically, one may focus on engagements regarding the 
execution environment. The main dependency between 
these three environments is that the execution architecture to 
a large degree drives the requirements for the development 
and operations architectures. For example if a 3 q 
heterogeneous, distributed execution architecture is 
selected, both the development and operations environments 
must reflect this. 

How can the delivery vehicle framework be useful? 

Re focus users and clients toward business solutions and 35 
away from technology issues. 

Help you link architecture planning deliverables to deliv- 
ering. 

Create an enterprise-wide view of the business capabili- 
ties enabled by technologies. 2 0 

Provide new architecture frameworks needed today to 
meet you* re a user's client's business needs. 

Provide guidance to define what architecture best meets 
you're a user's client's business needs. 

Provide standard architecture frameworks and best prac- 2 s 
tices to build these architectures. 

During a high-level architecture design, help the user 
identify architecture services the user wiU need to address, 
by providing a logical level discussion one can use to assess 
types of base services and products needed for the specific 30 
situation. 

When Delivery Vehicles are implemented, they reduce 
time to implement business solutions by providing "Starter 
Kits" architectures. 

When Delivery Vehicles are implemented, they leverages 35 
technology across the business by: 

reducing operations and maintenance costs by limiting the 
number of different technologies and skills required to 
support these technologies. 

reducing technology costs for execution & development. 40 
Note: The Delivery Vehicle Framework presents a way to 
organize technology architecture information. When pre- 
senting this type of contentclient, one may need to tailor the 
information they present based on the client's background 
and the terminology they are familiar with. 45 
Technology Generation Selection 
Introduction 

This section should assist an architect in understanding 
the characteristics of, and the implications from selecting, a 
specific technology generation. The strengths and weak- 50 
nesses of each technology generation should be understood 
when planning and designing a system. When identifying 
the core technologies to be used in an architecture, a view of 
the client's existing IT architecture 600, guiding principles 
602 and business imperatives 604 should be taken into 55 
consideration, as depicted in FIG. 6. 

It is important to realize that a distinct, static division does 
not exist between the different technology generations. It is 
possible that an architecture may consist of components 
from more than one generation, 60 

The goal should be to understand the pros and cons of the 
different technology options available for each component 
and to select the most appropriate one based on the client's 
requirements. 

It is becoming more important to leverage existing sys- 65 
tems and integrate them with new applications. A typical 
scenario can involve mainframe legacy systems acting as 
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servers in a client server architecture, application servers 
being accessed from both traditional GUI clients built in 
Powerbuilder and Visual Basic and from Web-based front 
ends accessing the application servers via a Web-server. 
General Considerations 

From a technology point of view a new custom-made 
application should generally use the most recent Architec- 
ture Generation to assure that the application will live longer 
by better being able to adapt to future changes. 

This implies that most applications should ideally be 
based on a Netcentric Architecture, rather than on a tradi- 
tional client/server or a host-based architecture. 

However choosing a generation is not just a technical 
decision. Often key technology architecture decisions are 
made as a result of factors which are completely non- 
technical in nature, such as financial factors, internal and 
client politics (say no more), and implementation/ 
operational considerations. 

When deciding whether to employ a Netcentric solution, 
i.e. incorporating Web-based user interfaces and Internet 
application styles, keep in mind that these technologies are 
not a panacea and should be used only when there is solid 
business reason. They require new investments in skills, 
tools, development and operations processes. Due to the 
relative immaturity of tools and products, they also represent 
additional risks both in technical terms, such as performance 
and reliability, and in strategic terms, such as vendor and 
product quality and stability. 

Regardless today each project should always consider the 
prospect of utilizing Netcentric technologies. It is important 
to evaluate whether the application can benefit from a 
Netcentric style implementation immediately or in the 
future. 

Even if a traditional client/server approach (e.g. using 
Visual Basic or PowerBuilder) is decided upon, the use of 
Netcentric concepts to produce significant reductions in 
software packaging and distribution costs should be consid- 
ered. Such concepts include three- or multi-tier architectures 
with more business logic residing on server, flexible security 
architecture, and user interface concepts that can be ported 
to a Web Browser at a later stage. 

A Netcentric architecture will usually still support devel- 
opment of client/server applications. The opposite is not 
often true since traditional client/server systems usually 
keep a substantial portion of the business logic on a fat 
client, while Netcentric architectures still favor keeping 
most business logic at the server side. Also Netcentric 
architectures tend to be more loosely coupled than (the still 
dominant two-tier) client/server systems. 

The following sections identify the main characteristics 
associated with a Netcentric, Client Server or Host based 
technology generation. This list should in no way be con- 
sidered complete and exhaustive but is included as a starting 
point from which the identification process may begin. 
Network Centric Architecture Generation 

If, based upon one's client's requirements, most of the 
statements in FIG. 7 are true, one should consider an 
application based upon the Netcentric technology genera- 
tion. 

The following details the importance of each of the 
statements in FIG. 7 and should assist one in identifying the 
appropriate answer for the specific client engagement. 
Existing Architecture and Infrastructure 700 

El. Other Netcentric applications been developed and 
placed in production. 

The user community is often less resistant to accept the 
use of new technology to address changing business 
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drivers if they are not completely unfamiliar with the 
characteristics of the technology. If an application 
based on a Netcentric architecture has already been 
successfully piloted or deployed, acceptance of addi- 
tional systems will be eased. 
E2. The client has significant technology skills within its 
IT department. 

This is especially important if the client plans on 
developing or operating the application themselves. 
A significant investment in training and changes to 
internal organizations may be necessary for success- 
ful deployment of this type of system. The client 
must have a culture that supports change. Some 
organizations are very conservative and strong, mak- 
ing it difficult to deliver a successful project using 
new technology. 
E3. The client has multiple hardware/operating system 

configurations for their client machines. 

In traditional client/server environments, distributing 
an application internally or externally for an enter- 
prise requires that the application be ported, recom- 
piled and tested for all specific workstation operating 
systems. Use of a Universal Client or web-browser 
may eliminate many of these problems by providing 
a consistent and familiar user interface on many 
different operating systems and hardware platforms. 
E4. The application will run on a device other than a PC. 

The momentum of the Internet is putting a lot of 
pressure on vendors of various devices to be web- 
enabled. Having the Internet infrastructure in place 
makes it more feasible for vendors to create new 
physical devices from which electronic information 
can be accessed. For example, Web televisions are 
gaining momentum. Now users can access the Inter- 
net from a television set. Network Computers, thin- 
client devices that download and run applications 
from a centrally maintained server are generating a 
lot of interest. Also, users want to have access to the 
same information from multiple physical devices. 
For example, a user might want to have access to 
his/her e-mail from a cellular phone, from a Web TV 
or their portable PC. 
E5. The current legacy systems can scale to serve a 

potentially large new audience. 

Expanding the user community of a legacy host or 
client/server system by including an audience which 
is external to the company can result in dramatic 
increases in system usage. The additional demand 
and increased usage placed on existing legacy sys- 
tems is often difficult to estimate or predict. Analysis 
must be conducted to ensure existing legacy systems 
and infrastructure can absorb this increase. 
Business Imperatives 702 

Bl. The client needs to reach a new external audience 

with this application. 

This is probably the main reason for selecting a Net- 
centric architecture. Through appropriate use of a 
Netcentric architecture it is often possible to gain 
exposure to new customers and markets. The client 
can often achieve significant competitive advantage 
by providing new services and products to its cus- 
tomers. Also this new channel makes it technically 
possible to develop a new generation of "market-of- 
one" products, where each customer can repeatedly 
and easy customize a product according to own 
preferences. 
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B2. The client needs to reach a large or diverse internal 
audience with this application. 
Configuration management of traditional client/server 
applications, which tend to be physically distributed 
5 across both the client and server, is a major issue for 

many corporations. The software distribution of such 
applications which are packaged as one large or a 
combination of a few large executables makes minor 
updates difficult for even a small scale user popula- 
30 tion. Every time an update is made, a process must 

be initiated to distribute new code to all client 
machines. The browser-centric application style 
offers an alternative to this traditional problem of 
distributing functionality to both internal and exter- 
is nal users. 

IT Guiding Principles 704 

Gl. The client is an early adopter of new technology. 
Implementation of a Netcentric architecture can help 
the client realize a number of business benefits. 
20 However, the introduction of new technology into an 

organization does have inherent risks and can result 
in a significant amount of change. The client should 
have a culture which can embrace these necessary 
changes. 

25 G2. Applications should be developed to handle non- 
dedicated or occasional users. 

Non-expert users need a simple to use and familiar 
interface in order to be able to use the application. As 
people grow accustomed to Web -browsers, this will 
30 be their preferred user-interface. The consistent 

interface provided by the Web-browsers will help 
reduce the learning curve necessary for becoming 
familiar with new applications. 
35 G3. Where appropriate, applications should be developed 

with multi-media capabilities for the presentation of 

data (text, sound, video, etc.). 

The ability to digitize, organize, and deliver textual, 
graphical and other information (e.g., video, audio, 
4Q etc.) in addition to traditional data to a broader 

audience, enables new methods for people and enter- 
prises to work together. Netcentric technologies 
(e.g., HTML documents, plug -ins, Java, etc.) and 
standardization of media information formats enable 
45 support for these types of complex documents and 

applications. Network bandwidth remains a perfor- 
mance issue. However advances in network tech- 
nologies and compression techniques continue to 
make richer media-enabled documents and applica- 
5Q tions more feasible on the Web. 

G4. The Execution, Operation and Development archi- 
tectures will be designed to support frequent releases of 
enhancements/modifications to production applica- 
tions. 

55 It is imperative that companies in the current market 
place be able to quickly modify their business pro- 
cesses in order to address changes in the industry. 
A Netcentric architecture simplifies frequent software 
releases for both internal and external users of the systems. 
60 Client/server Network Generation 

If, based upon a client's requirements, most of the state- 
ments of FIG, 8 are true, one should consider an application 
based upon the Client Server technology generation. 
The following section details the importance of each of 
65 the statements found in FIG. 8 and should assist one in 
identifying the appropriate answer for your specific client 
engagement. 
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Existing Architecture and Infrastructure 800 

El. Other Client Server applications been developed and 
placed in production and the client IT organization 
contains personnel familiar with client server architec- 
ture concepts. 

As with any new technology, there is a learning curve 
related to attaining client server development skills. 
The development process is often much more effi- 
cient when familiar tools and environments are used. 
The introduction of new technology can also create 
instability in the operations environment. Client/ 
server systems still represent a new technology to 
many IT departments. 
Business Imperatives 802 

Bl. The application will be used only by an internal user 

community. 

Software distribution is a concern for traditional client 
server computing environments due to the fact that 
executable and data files need to reside on the client 
hard drive. Distribution to a user community outside 
of the client's organization is even more difficult to 
implement and manage and will probably be limited 
to a few key business partners. 
B2. The application requires an advanced, dynamic, and 

integrated user interface for expert users. 

State of the art 4GL and 3GL development languages 
will support advanced user interfaces which require 
a significant degree of context management between 
fields and windows. Web-based user interfaces do 
not support such interfaces well yet. 
B3. Session performance is critical to the application or 

sub-second response times are required for successful 

use. 

Client server applications can provide response times 
necessary to support transaction intensive mission 
critical systems. Application logic and business data 
can be distributed between the client and server for 
optimal efficiency. Web-based interfaces still have an 
inherent overhead due to the connectionless commu- 
nication and constant downloading of data, format- 
ting information and applet code. 
. B4. The application needs to support off-line mobile 

users. 

Mobile computing is becoming more prevalent in the 
work place, therefore, connectivity to a server can 
not be assumed for all user classes. A client server 
architecture allows for the distribution of application 
logic and/or data between the server and client. 
Replication of data and logic is usually necessary for 
applications that are run on portable computers. 
IT Guiding Principles 804 
Gl. The client maintains their applications internally and 
the IT department has the necessary resources, organi- 
zations and processes to maintain a Client Server 
application. 

Introduction of a Client Server application to a com- 
pany's production environment can require a great 
deal of change to the Execution, Operations and 
Development architectures required to develop, run 
and support the production systems. Before a Client 
Server application is developed, it is important that 
the client identify how a system of this type will fit 
within the company's strategic technology plan. 
Host Architecture Generation 

If yclients business and technical requirements meet the 
following system characteristics, you should consider an 
application based upon the Host technology generation. 
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The following section details the importance of each of 
the statements found in FIG. 9 and should assist you in 
identifying the appropriate answer for your specific client 
engagement. 

Existing Architecture and Infrastructure 900 
El. The client currently maintains and operates host based 
applications and the IT organization contains personnel 
familiar with the development and operation of these 
types of applications. 

Few organizations introduce solely host based produc- 
tion systems. Usually the infrastructure for this type 
of systems already exists. New development is 
uncommon, typically existing legacy systems need 
to be extended. 

Host systems usually have a mature and stable opera- 
tions environment. Note that mainframe expertise 
may be expensive and in high demand 
Business Imperatives 902 

Bl. The application will only be used by a dedicated, 

expert user community where a GUI is not needed. 

A dedicated work force with low turnaround, skilled in 
the use of character based 3270 applications, elimi- 
nates the need for a GUI interface. 
B2. The application requires a high volume of repetitive 

transactions. 

The high degree of processing power provided by 
mainframes allows for the development of applica- 
tions with very high performance requirements. 
B3. The application has a requirement for significant 

batch processing. 

Mainframes are probably still the most powerful plat- 
forms for large scale batch processing. Mature tools 
exist for scheduling, recovery/restart, sorting, 
merging, and moving large sets of data. 
B4. End users can maintain a physical connection to the 

host at all times. 

Physical connection to the host is required for use of the 
applications. Methods of mobile computing with 
distribution of data or business logic is not possible. 
B5. The application will need to support a large number 

of users (> 1000). 

The processing power of today's mainframe lends itself 
well to the development of large scale, mission 
critical applications with a large user base. 
IP Guiding Principles 904 

Gl. The Client has the resources, organizations and 
processes necessary for the development and operation 
of a Host based application. 

Before a Host based application is developed, it is 
important that the client identify how a system of this 
type will fit within the company's strategic technol- 
ogy plan. 

G2. Reliance upon a single vendor (IBM) for technology 
solutions is acceptable. 

Selection of a host based architecture inherently locks 
the client into dependence upon one vendor for its 
technology solutions. While IBM is a reputable, 
stable company it may be important to ensure that 
the client's long term business strategy will be 
supported by IBM's technology vision and direction. 
G3. Centralized application and data is an acceptable 

strategy. 

A pure host based architecture eliminates the possibility 
of distributing data or business logic to the client. 
This removes some of the application performance 
benefits which can be seen by a distribution strategy, 
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however, centralized access to the business logic and 
business data can improve operational stability and 
lower costs. 

A current trend is to transform mainframe based legacy 
systems into data — and application servers in a 5 
multi-tiered client/server or Netcentric architecture. 
Overview of the Frameworks 

One may ask: what frameworks one should use? This 
portion of the specification should help one understand: 
when the various frameworks in SAF can be useful 10 
how the frameworks are related 
Frameworks Related to Delivery Vehicles 

Most of the frameworks in SAF address various a spects 
of Delivery Vehicle architectures. 

SAF provides access to the user's thought leadership and 
architecture frameworks for Execution, Development and 
Operations environments. Very briefly, SAF covers: 

The Core Execution Architecture frameworks for the 
different architecture generations (Host, Client/Server 
and Netcentric). Most users will primarily use the 
Netcentric framework. 20 
The Execution Architecture Extensions. This is a collec- 
tion of the most common delivery vehicles that are built 
for clients. These frameworks extend the core frame- 
works with services specific for a particular delivery 
vehicle. 25 
The Development Architecture Framework. Should help 
one establish and operate a high-quality development 
environment. 

The Operations Architecture Framework. Should help one 
establish and operate a high-quality operations envi- 30 
ronment. 

To learn more about what Delivery Vehicles are, see the 
Delivery Vehicle Overview section. This page explains 
the relationships between Architecture Generations, 
Application Styles and Environments. 35 
Framework Extensions and Other Frameworks 

The remaining frameworks in SAF are special purpose 
frameworks that may not directly fit into the current Deliv- 
ery Vehicle definition. 

They may be extensions to the delivery vehicle frame- 40 
works such as Call Center, Mobile, eCommerce Application 
Framework, Middleware or Component Technologies. 
Framework Recommendations 

The frameworks in SAF address different aspects and 
areas of technology and application architecture. No single 45 
framework may cover this scope. Depending on the phase of 
one's project and the type of applications one's project will 
deliver, one may need to use different specialized frame- 
works. 

Most implementations today may begin by considering 50 
the Netcentric Execution framework, then adding extensions 
for the delivery vehicles or specific technologies that your 
project will use. Keep in mind, however, the Development 
and Operations frameworks. Also, remember that some 
architectures will need to be built on multiple frameworks, 55 
most likely involving the Integration framework to bridge 
between them. 

This section lists all the frameworks currently available in 
SAF, indicates when they may be useful, and how it relates 
to other frameworks: 60 
Netcentric 
When is it useful? 

This framework constitutes the core of a modem netcen- 
tric and client/server execution architecture. It will help one 
plan and design one's architecture by understanding what 65 
components a typical netcentric architecture should consist 
of. 
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Netcentric Architecture Framework 
Framework Overview 

Introduction 

The Netcentric Architecture Framework identifies those 
run-time services required when an application executes in 
a Netcentric environment. As shown in FIG. 10, the services 
can be broken down into logical areas: Presentation Services 
1000, Information Services 1002,1004, Communication Ser- 
vices 1006,1008, Communication Fabric Services 1010, 
Transaction Services 1012,1014, Environment Services 
1016,1018, Base Services 1020 and Business Logic 1022, 
1024. This framework is an evolution of the Client Server 
New Age Systems Framework and is useful for technical 
architects involved in the selection, development and 
deployment of technical architectures in a Netcentric envi- 
ronment. More discussion of each of these logical areas is 
provided below. See also FIGS. 11 and 12, which are 
detailed diagrams of the components of the Netcentric 
Architecture Framework found in FIG. 10. 
Netcentric Computing Top 10 Points 

Netcentric computing represents an evolution — it builds 
on and extends, rather than replaces, client/server. 

Netcentric computing has a greater impact on the entire 
business enterprise, hence greater opportunity and risk. 

Definitions of Netcentric may vary. One is about reach 
and content. 

Netcentric is not just electronic commerce; it can impact 
enterprises internally as well. 

You can begin identifying Netcentric opportunities for 
clients today. 

There are three basic types of Netcentric applications: 

advertise; inquiry; and fully interactive. 
One can underestimate the impact of Netcentric on infra- 
structure requirements. 
Build today s client/server engagements with flexibility to 
extend to Netcentric. 
Netcentric Computing Definition 

Netcentric Computing also called Netcentric 
Architecture, Netcentric Technology, etc. is an emerging 
architecture style which expands the reach of computing 
both within and outside the enterprise. Netcentric enables 
sharing of data and content between individuals and appli- 
cations. These applications provide capabilities to publish, 
interact or transact. Netcentric represents an evolution of 
Client/Server which may utilize internet technologies to 
connect employees, customers, and business partners. 
Client/Server vs. Netcentric Computing (NCC) 

NCC is a new style of computing that expands on the 
technological base already provided by traditional client/ 
server systems. Many of the traditional client/server design 
concepts and considerations still apply to NCC. 

The important differences between client/server systems 
and NCC systems are: 
The way in which the application logic is distributed to 
clients is different in NCC and traditional client/server 
systems. In NCC systems, application logic can be 
packaged into components and distributed from a 
server machine to a client machine over a network. In 
traditional client/server systems, the application logic is 
split between the client and the server on a permanent 
basis; there is no dynamic distribution of application 
logic. 

The number of tiers in NCC and traditional client/server 
systems is different. NCC extends the traditional two- 
tier client/server architecture to a n-tier architecture. 
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The client in NCC systems is different from a client in 
traditional client/server systems. The client in a NCC 
system is a standardized universal one; a NCC appli- 
cation can execute within a client that can run on 
multiple operating systems and hardware platforms. In 
traditional client/server systems, the client is custom- 
made for a specific operating system and hardware 
platform. 

The way in which NCC and traditional client/server 
systems can be extended and adapted is different. 
Components enable NCC systems to be adaptable to a 
variety of distribution styles, from a "thin client" to a 
"fat client". In comparison, traditional client/server 
systems, once designed and built, cannot be adapted for 
use on more than one computing style 

Tiers 

Similarly to traditional client/server architectures, Net- 
centric architectures support a style of computing where 
processes on different machines communicate using mes- 
sages. In this style, "client" processes delegate business 
functions or other tasks (such as data manipulation logic) to 
one or more server processes. Server processes respond to 
messages from clients. 

Business logic can reside on both client and server. 
Clients are typically PCs or Workstations with a graphical 
user interface running in a Web browser. Servers are usually 
implemented on UNIX, NT or mainframe machines. 

A key design decision for a client/server system is 
whether it should be two-tiered or multi-tiered and how 
business logic is distributed across the tiers. In Netcentric 
architectures there is a tendency to move more business 
logic to the server tiers, although "fatter" clients are becom- 
ing more popular with newer technologies such as Java and 
ActiveX. 

Two-Tiered Architectures 

Two-tiered architecture describes a distributed application 
architecture in which business applications are split into 
front -ends (clients) and back-ends (servers). Such a model of 
computing began to surface in the late 1980s and is the 
prominent configuration in use today by companies which 
have attempted to migrate to client/server based computing. 
Advantages 

At a minimum, a two-tiered client/server architecture 
assumes that an application's presentation logic resides on 
the client and its data management logic resides on the 
server. This style of computing became attractive to early 
adopters of client/server because it clearly addresses the 
inadequacies of a character-based interface. That is, it allows 
PC-based clients to introduce a graphical user interface 
(GUI) into the application environment. 

Allows rapid development "out-of-the-box" 

Decreased communication overhead because of a direct 
connection (for a small number of users) 

Allows the distribution of the program's logic 
(application, presentation, data management) 
Limitations of Two-Tiered Architecture 

The use of two-tier tools has resulted in a defacto "client- 
heavy" or "fat-client" two-tiered model where the presen- 
tation and application logic resides on the client and data 
management resides on the server. In fact, the use of these 
tools "out-of-the-box" assumes the adoption of such a 
model. Unfortunately, such an architectural model falls short 
of addressing many important issues required of an 
enterprise -wide information architecture. This model of 
computing was actually developed for less-demanding PC 
environments where the database was simply a tool for 
decision support. 
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Limitations 

Limited/cost prohibitive Scalability 

Limited availability 

Limited reliability 

Security Deficiencies 

Network/Database bottlenecks 

Low implementation flexibility 

Limited Asynchronous processing 
Three-Tiered or Multi-tiered Architectures 

Three-tiered architecture describes a distributed applica- 
tion architecture in which business applications are sepa- 
rated into three logical components: presentation and 
control, application logic, and data management. These 
logical components are "clean layered" such that each runs 
on a different machine or platform, and communicates with 
the other components via a network. 

A three -tiered architecture is often enhanced by the inte- 
gration of distributed transaction processing middleware. 
This model of computing is often termed the "enhanced" 
client/server model. Most Netcentric architectures use a 
three- or four tiered approach with a web server and poten- 
tially a separate application server layer. 

In the enhanced client/server model, all presentation and 
control logic resides on the client, all application logic 
resides on multiple back-end application servers, and all 
data management logic resides on multiple back-end data- 
base servers. 
Advantages 

In contrast to mainframe and two-tiered client/server 
computing models, the principle advantage with a three- 
tiered enhanced client/server architecture is that it provides 
the benefits of a GUI application, but also provides a level 
of integrity and reliability found in mainframe centralized 
computing. That is, it will evolve to serve high-volume, 
high-integrity, and high-availability environments. 

Location and implementation transparency — The use of a 
transaction manager such as Tuxedo allows for service 
location independence. 
Distribution of logic to optimal resource — Since the 
application and database functions reside on their own 
physical devices, each can be optimally tuned for the 
work they perform. 
Database scaleable on throughput — In the enhanced 
three -tiered client/server model, client applications no 
longer connect directly to database servers. Instead, 
only application servers connect to the database serv- 
ers. 

Security over service resources — With the application 
logic residing on back-end application servers, security 
over the applications is made possible at various levels. 

Redundancy and resiliency of services — A major disad- 
vantage prominent in other models of computing is 
"single point of failure 

Optimization of personnel resources — Developers can be 
utilized for specific talents in each tier. 

Allows for asynchronous and standardized messaging — 
The enhanced client/server model is really a superset of 
the RPC-based function shipping model which pro- 
vides features such as asynchronous, event-driven pro- 
gramming. 

Administration, configuration, prioritization — The use of 
a transaction manager enables servers to be added, 
removed, or restarted dynamically. This allows for very 
robust, scaleable, and flexible applications. 
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Disadvantages 

Three-tier architectures are highly flexible. This flexibility 
comes with the cost of being more complex to implement. 
Limitations 

Additional tool (middleware) selection 

Longer implementation times 

Greater development costs associated with additional tier 
More complex planning 
Additional Skills 
Extra Hardware 

Greater complexity for maintenance, configuration man- 
agement 

Presentation 1000 

Presentation Services enable an application to manage the 
human-computer interface. This includes capturing user 
actions and generating resulting events, presenting data to 
the user, and assisting in the management of the dialog flow 
of processing. FIG. 13 illustrates several components of the 
Presentation area of the Netceotric Architecture Framework. 

Exemplary products that may be used to enable this 
component include Visual Basic; PowerBuilder; C++; Win- 
dows 3.X/NT/95; X-Windows/Motif; Visual C++; Borland 
Delphi; AC FOUNDATION for FCP. 

The products listed as candidates for specific components 
here and below should be used with care. These examples do 
not provide an all-inclusive list, nor do they necessarily 
represent the current market leaders. They are there to 
provide an example of products that may enable the com- 
ponent services. 
Window System 1300 

Typically part of the operating system, the Window Sys- 
tem Services provide the base functionality for creating and 
managing a graphical user interface (GUI) — detecting user 
actions, managing windows on the display, and displaying 
information in windows. 
Implementation Considerations 

Windowing systems expose their functionality to appli- 
cation programs through a set of application programming 
interfaces (APIs). For the Microsoft windowing platform, 
this API is called Win32. The Win32 API is a documented 
set of over 500 C functions that allow developers to access 
the functionality of the windowing system as well as various 
other operating system functions. While it is possible for 
developers to directly call the Win32 API or its equivalent on 
other platforms using a C language compiler, most business 
application development is done using higher level devel- 
opment languages such as Visual Basic or PowerBuilder 
which make the lower level calls to the operating systems on 
behalf of the developer. 

Exemplary products that may be used to enable this 
component include Microsoft Windows; Windows 95; Win- 
dows NT; Macintosh OS; Program Manager for OS/2; 
X- Windows/Motif; JavaOS 
Desktop Manger 502 

Desktop Manager Services implement the desktop meta- 
phor. The desktop metaphor as the name suggests is a style 
of user interface that tries to emulate the idea of a physical 
desktop allowing you to place documents on the desktop, 
launch applications by clicking on a graphical icon, or 
discard files by dragging them onto a picture of a waste 
basket. Most Window Systems contain elementary Desktop 
Manager functionality (e.g., the Windows 95 desktop), but 
often more user friendly or functional Desktop Manager 
Services are required. 
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Microsoft Windows 95 task bar; Norton Navigator; Xerox 
Tabworks; Starfish Software Dashboard 
Product Considerations 
Exemplary products that may be used to enable this 
5 component include: 

Microsoft Windows 95 task bar — provides a launch bar 
which allows users to access recently used documents, 
launch applications, or switch between active applica- 
tions. The Windows 95 desktop and launch bar are 
10 programmable allowing users to extend and customize 
the desktop manager for their specific application. For 
example, the desktop can be extended with icons or 
Start Menu options for creating a new customer 
account or finding an order, 
15 Norton Navigator — provides multiple virtual desktops, 
enhanced file management including direct FTP 
connectivity, long file name support for some 16-bit 
applications, file un-erase, and other features; targeted 
at users who often interact with the Windows 95 
20 desktop. 

Xerox Tabworks — presents the user with a notebook 
metaphor for application and document access; allows 
creation of tabbed sections which contain related files 
(e.g., Winston Account or New Product Launch) for 
25 easier access. 

Starfish Software Dashboard — a desktop utility designed 
to simplify application and system management; pro- 
vides quick launch buttons, system resource gauge, 
drag-and^Irop printing and faxing, calendar, etc. 
30 Form 1304 

Form Services enable applications to use fields to display 
and collect data. A field may be a traditional 3270-style field 
used to display or input textual data, or it may be a graphical 
field such as a check box, a list box or an image. Form 
35 Services provide support for: 

Display — support the display of various data types (e.g., 
text, numeric, date, etc.) in various formats (e.g., American/ 
European date, double-byte characters, icons, etc.) 

Input/ Validation — enable applications to collect informa- 
40 tion from the user, edit it according to the display options, 
and perform basic validation such as range or format checks. 

Mapping Support — eliminate the need for applications to 
communicate directly with the windowing system; rather, 
applications retrieve or display data by automatically copy- 
45 ing the contents of a window's fields to a copybook structure 
in memory. These Services may also be used to automate the 
merging of application data with pre-defined electronic form 
templates. 

Field Interaction Management — coordinate activity 

50 across fields in a window by managing field inter- 
dependencies and invoking application logic based on the 
state of fields and user actions. For example, the Field 
Interaction Manager may disable the "OK" button until all 
required input fields contain valid data. These services 

55 significantly reduce the application logic complexity inher- 
ent to an interactive windowed interface. 
Implementation Considerations 

In traditional client/server applications, Forms are win- 
dows that contain widgets (text fields, combo-boxes, etc.) 

60 and business logic. Form development tools such as Visual 
Basic, PowerBuilder, etc. allow the Form designer to specify 
page layout, entry fields, business logic, and routing of 
forms. From a developers perspective, these products typi- 
cally expose Form and control handling functionality as a set 

65 of proprietary or product specific APIs. 

In addition to the traditional tools (e.g., Visual C++, 
Visual Basic, PowerBuilder), Netcentric technologies have 
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introduced new tools that can be used to develop Forms. For 
example, a developer can use Symantec Visual Cafe" to 
create a Java application that will execute directly on the 
users desktop without any interaction with a browser. 

Today most Netcentric applications are Web based and are 
launched from the Web browser. Additionally, one is now 
beginning to see other types of Netcentric solutions. For 
example, PointCast is a Netcentric application located on the 
users machine; it relies on the Internet to deliver stock 
prices, news headings, sports updates, etc. to the user. 
However, it is not launched from the Web browser — it is its 
own application. In the future there will be more Netcentric 
applications that use this approach for delivering informa- 
tion. 

Product Considerations 

What level of technical support, documentation, and training 
is required to ensure the productivity of developers? 

The extent of support (on-site, phone, bulletin board, 
world-wide, etc.), quality of documentation, and availability 
and location of education/training should be considered. 
What functions are required in the control set? 

At the minimum a tool should support basic widgets (push 
buttons, list boxes, etc.), window styles, (multi- window, 
multi-document, paned -window), and menu styles, along 
with validation and inter-application communication. Con- 
sideration should also be given as to the extensibility of the 
toolset via add-ons and third party products. 
Can the tool be used for both prototyping and GUI design? 

The ability to use a single tool for both prototyping and 
GUI design will reduce the development learning curve. 
One should also consider how well the tool integrates will all 
other development tools. 
What platform(s) are supported? 

The platform(s) that must be supported, i.e., MS-DOS, 
Windows, IBM OS/2, UNIX, or UNIX Motif, is an impor- 
tant consideration, as are any hardware restrictions. 
What type of learning curve is associated with the tool? 

Developers using the product should be able to become 
productive quickly. Factors which reduce the learning curve 
include an easy to leam and intuitive interface, thorough and 
clear documentation, and on-line help. 
If the tool is also going to be used for application 
development, how well does the tool perform during pro- 
duction? 

Computational, network, data retrieval, and display 
speeds differ for products. Factors to consider are whether 
the application will consist of heavy data entry, transaction 
processing, or a large user base. 
How much does the tool cost? 

Product components, maintenance agreements, upgrades, 
run -time licenses, and add-on packages should be consid- 
ered. 

Does the product integrate with other tools and/or support 
other tools in the development and execution environments? 

It is important to determine how well the product inte- 
grates with other design and development tools, presentation 
services (graphics, multi-media, etc.), data access services 
(databases and database API libraries), distribution services 
(distributed TP monitor), transmission services (SNA, 
HLLAPI, etc.), data dictionary, desktop applications, and 
programming languages for call-out/call- in. Additional con- 
sideration should be given to add-on and third-party 
products/enhancements such as specialized widgets, report 
writers and case tools. 

Will the tool be used with a large development team? 

If the development team is more than 5 people, a tool 
should provide support for multiple developers. This support 



^8,068 Bl 

38 

includes features such as object check-in/check-out, a cen- 
tral design repository for the storage of application objects 
and user interface definitions, and version control. 
Additionally, the development team should be able to 
5 cleanly divide the application(s) into pieces which can be 
worked on by multiple people. 

What protocols are used to communicated with the data- 
base? 

Important considerations include the supported databases 
and protocols used to communicated with the databases. The 
tool must support the selected database. Additionally, if the 
database selection may change, it is important that the tool 
have the ability to support other databases with minimal 
impact on the application development. Native database 
interfaces tend to have better performance than open stan- 
15 dards such as ODBC. 

Will the design tool be used for programming of client 
applications? What programming language is supported? 

If the design tool is used for programming, there are 
several features of a tool which must be considered. These 
20 features can have an impact on the productivity of 
programmers, performance of the applications, skill sets 
required, and other tools required for development. These 
features include: 
What programming language is supported? Is the pro- 
25 gramming language interpretive or compiled? Is it 
object oriented or structured procedural language? 
Does the tool support programming extensions to 

Dynamic Link Libraries? 
What are the debugging capabilities of the tool? 
30 Is the tool scalable? 

The tool should be scalable to support growth in appli- 
cation size, users, and developers. 

Exemplary products that may be used to implement this 
component include JetForms JetForm Design; Lotus Forms; 
35 Visual Basic. 

JetForms JetForm Design — provides tools to design, fill, 
route, print and manage electronic forms, helping orga- 
nizations reduce costs and increase efficiency by auto- 
mating processing of forms across local and wide area 
40 networks as well as the Internet. Lotus Forms — Lotus 
Development Corporations electronic forms software 
provides tools to design, route and track forms to 
automate business processes for the workgroup or the 
extended enterprise. 
45 Lotus Forms is designed to run with Lotus Notes or as a 
standalone application. It is comprised of two parts: Forms 
Designer, an application -development version, and Forms 
Filler, a runtime version for users. Visual Basic — a devel- 
opment tool that provides a comprehensive development 
50 environment for building complex applications. 
User Navigation 1306 

User Navigation Services provide a user with a way to 
access or navigate between functions within or across appli- 
cations. Historically, this has been the role of a text-based 
55 menuing system that provides a list of applications or 
activities for the user to choose from. 

Client/server technologies introduced new navigation 
metaphors. A method for allowing a user to navigate within 
an application is to list available functions or information by 
60 means of a menu bar with associated pull -down menus or 
context-sensitive pop -up menus. This method conserves 
screen real-estate by hiding functions and options within 
menus, but for this very reason can be more difficult for first 
time or infrequent users. This point is important when 
65 implementing electronic commerce solutions where the tar- 
get customer may use the application only once or very 
infrequently (e.g., purchasing auto insurance). 
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Additionally, client/server development tools such as 
Visual Basic and PowerBuilder do not provide specific 
services for graphical navigation, but the effect can be 
recreated by selecting (i.e., clicking on) graphical controls, 
such as picture controls or iconic push-buttons, programmed 
to launch a particular window. 

A major advantage of the graphical user interface is the 
fact that it allows multiple windows to be open at one time. 
Implementation Considerations 

Is there a need to manage multiple instances of a window 
object? 

Windows Interaction Manager provides the application 
with facilities to open multiple instances of the same win- 
dow. This component provides an option parameter that will 
let the application developers enable or disable the ability to 
open the same window with the same key data (that is, a 
duplicate instance). 

Do you need to pass messages between windows? 

Windows Interaction Manager provides the facility to 
pass messages between windows within one application. 
This allows one window to trigger an event/action on 
another related window. 

Do multiple applications need to pass messages between 
each other? 

Windows Interaction Manager provides the facility to 
pass messages between windows from different applications 
residing on the same machine. This allows one window to 
trigger an event/action on an related window when certain 
actions (user or environment) occur. 

If information needs to be shared between applications on 
different machines, Window Interaction Management can- 
not be used. This type of data sharing requires a special 
architecture component called Communication, which is 
more network orientated. 

Is there a need for object registration/de-registration? 

Windows Interaction management allows the application 
to control and manage the opening and closing of multiple 
windows by — maintaining the parent-child relationship, 
controlling multiple instances of similar windows, maintain- 
ing key data-window relationship. This allows the user to 
work in a controlled and, well managed, environment. 
Web Browser 1308 

Web Browser Services allow users to view and interact 
with applications and documents made up of varying data 
types, such as text, graphics, and audio. These services also 
provide support for navigation within and across documents 
no matter where they are located, through the use of links 
embedded into the document content. Web Browser Services 
retain the link connection, i.e., document physical location, 
and mask the complexities of that connection from the user. 
Web Browser services can be further subdivided into: 
Browser Extension, Form, and User Navigation. 
Parlez-vous Internet? 
The Elements of Web Style 

Language philosopher Benjamin Whorf once said, "We 
dissect nature along lines laid down by our native language. 
Language is not simply a reporting device for experience, 
but a defining framework for it." This notion is especially 
true when applied to the World Wide Web. The evolution of 
the Web from a rigid, text-centric village to an elastic, 
multimedia-rich universe has been driven by modifications 
to the languages behind it. The Internet is at a crucial point 
in its development as a number of enhancements for extend- 
ing Web technology come under scrutiny by Internet stan- 
dards groups. These enhancements will ultimately push the 
Web into the realms of distributed document processing and 
interactive multimedia. 
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SGML: in the beginning . . . 

Although the World Wide Web was not created until the 
early 1990s, the language behind it dates back to the genesis 
of the Internet in the 1960s. Scientists at IBM were working 

5 on a Generalized Markup Language (GML) for describing, 
formatting, and sharing electronic documents. Markup 
refers to the practice in traditional publishing of annotating 
manuscripts with layout instructions for the typesetters. 

In 1986, the International Standards Organization (ISO) 
adopted a version of that early GML called Standard Gen- 
eralized Markup Language (SGML), SGML is a large and 
highly-sophisticated system for tagging documents to ensure 
that their appearance will remain the same regardless of the 
type of platform used to view them. Designers use SGML to 
create Document Type Definitions (DTDs), which detail 

15 how tags (also known as format codes) are defined and 
interpreted within specified documents. These tags can be 
used to control the positioning and formatting of a docu- 
ment's text and images. SGML is used for large, complex, 
and highly-structured documents that are subject to frequent 

20 revisions, such as dictionaries, indexes, computer manuals, 
and corporate telephone directories. 
HTML: SGML for dummies? 

While creating the World Wide Web in the early 1990s, 
scientists at CERN discovered that in spite of its power and 

25 versatility, SGML's sophistication did not allow for quick 
and easy Web publishing. As a result, they developed 
HyperText Markup Language (HTML), a relatively simple 
application of SGML. This simplicity has contributed to the 
exponential growth of the Web over the last few years. 

30 HTML files are written in plain text and can be created using 
any text editor from the most robust Web page authoring 
software (such as Microsoft's FrontPage or Sausage Soft- 
ware's HotDog) to the anemic Notepad utility included with 
Microsoft's Windows operating system. 

35 As with many languages, HTML is in a state of constant 
evolution. The World Wide Web Consortium W3C oversees 
new extensions of HTML developed by both software 
companies (such as Microsoft and Netscape 
Communications) and individual Web page authors and 

40 ensures that each new specification is fully-compatible with 
previous ones. Basic features supported by HTML include 
headings, lists, paragraphs, tables, electronic forms, in-line 
images (images next to text), and hypertext links. Enhance- 
ments to the original HTML 1.0 specification include 

45 banners, the applet tag to support Java, image maps, and text 
flow around images. 

The W3C also approved the specification for version 4.0 
of HTML (http://www.w3.org/TR/REC-html40). This speci- 
fication builds upon earlier iterations of HTML by enabling 

50 Web authors to include advanced forms, in-line frames, and 
enhanced tables in Web pages. HTML 4.0 also allows 
authors to publish pages in any language, and to better 
manage differences in language, text direction, and character 
encoding. 

55 Perhaps most significantly, HTML 4.0 increases authors' 
control over how pages are organized by adding support for 
Cascading Style Sheets CSS Style sheets contain directions 
for how and where layout elements such as margins, fonts, 
headers, and links are displayed in Web pages. With CSS, 

60 authors can use programming scripts and objects to apply 
multiple style sheets to Web pages to create dynamic con- 
tent. CSS can also be used to centralize control of layout 
attributes for multiple pages within a Web site, thus avoiding 
the tedious process of changing each page individually. 

65 Dynamic HTML: Dyn-o-mite! 

HTML's simplicity soon began to limit authors who 
demanded more advanced multimedia and page design 
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capabilities. Enter Dynamic HTML DHTML As an exten- 
sion of HTML, DHTML allows Web pages to function more 
like interactive CD-ROMs by responding to user-generated 
events. DHTML allows Web page objects to be manipulated 
after they have been loaded into a browser. This enables 
users to shun plug-ins and Java applets and avoid 
bandwidth-consuming return trips to the server. For 
example, tables can expand or headers can scurry across the 
page based on a user's mouse movements. 

Unfortunately, the tremendous potential offered by 
DHTML is marred by incompatible standards. At the heart 
of the DHTML debate is a specification called the Document 
Object Model DOM The DOM categorizes Web page 
elements — including text, images, and links — as objects and 
specifies the attributes that are associated with each object. 
The DOM makes Web document objects accessible to 
scripting languages such as JavaScript and VisualBasic 
Script (VBScript), which can be used to change the 
appearance, location, and even the content of those objects 
in real-time. 

Microsoft's Internet Explorer 4.0 supports a W3C "Work- 
ing Draft" DOM specification that uses the CSS standard for 
layout control and Web document object manipulation. In 
contrast, Netscape's implementation of DHTML in Com- 
municator 4.0 uses a proprietary "Dynamic Layers" tag, 
which assigns multiple layers to a page within which objects 
are manipulated. As a result, Web pages authored using 
either version of DHTML may not be viewed properly using 
the other's browser. XML: X marks the spot 

HTML 4.0 and Dynamic HTML have given Web authors 
more control over the ways in which a Web page is dis- 
played. But they have done little to address a growing 
problem in the developer community: how to access and 
manage data in Web documents so as to gain more control 
over document structure. To this end, leading Internet devel- 
opers devised Extensible Markup Language (XML), a 
watered-down version of SGML that reduces its complexity 
while maintaining its flexibility. Like SGML, XML is a 
meta-language that allows authors to create their own cus- 
tomized tags to identify different types of data on their Web 
pages. In addition to improving document structure, these 
tags will make it possible to more effectively index and 
search for information in databases and on the Web. 

XML documents consist of two parts. The first is the 
document itself, which contains XML tags for identifying 
data elements and resembles an HTML document. The 
second part is a DTD that defines the document structure by 
explaining what the tags mean and how they should be 
interpreted. In order to view XML documents, Web brows- 
ers and search engines will need special XML processors 
called "parsers." Currently, Microsoft's Internet Explorer 
4.0 contains two XML parsers: a high-performance parser 
written in C++ and another one written in Java. 

A number of vendors plan to use XML as the underlying 
language for new Web standards and applications. Microsoft 
uses XML for its Channel Definition Format, a Web-based 
"push" content delivery system included in Internet Explorer 
4.0. Netscape will use XML in its Meta Content Framework 
to describe and store metadata, or collections of information, 
in forthcoming versions of Communicator. XML is currently 
playing an important role the realm of electronic commerce 
via the Open Financial Exchange, an application developed 
by Microsoft, Intuit, and CheckFree for conducting elec- 
tronic financial transactions. Similarly, HL7, a healthcare 
information systems standards organization, is using XML 
to support electronic data interchange EDI of clinical, 
financial, and administrative information (hup:// 
www.mcis.duke.edu/standards/HL7/sigs/sgml/index.html). 



?8,068 Bl 

42 

Meet Cousin VRML 

In 1994, a number of Internet thought leaders, including 
Tim Berners-Lee — the "father" of the Web — met to deter- 
mine how they could bring the hot, new technology known 

5 as virtual reality VR to the Web. VR refers to the use of 
computers to create artificial and navigable 3-D worlds 
where users can create and manipulate virtual objects in real 
time. This led to the creation of Virtual Reality Modeling 
Language (VRML — pronounced "ver-mul"). VRML is tech- 

10 nically not a markup language because it uses graphical 
rather than text-based file formats. 

In order to create 3-D worlds and objects with VRML, 
users need a VRML editor such as Silicon Graphics* Cosmo 
Worlds (http://cosmo.sgi.com/products/studio/vvorlds). To 

15 view VRML content, users need either a VRML browser or 
a VRML plug-in for standard HTML browsers. Leading 
VRML plug-ins include Cosmo Player from Silicon Graph- 
ics (http://vrml.sgi.com/cosmoplayer), Liquid Reality from 
Microsoft's DimensionX subsidiary (http:// 

20 www.microsoft.com/dimensionx), OZ Virtual from OZ 
Interactive (http://www.oz.com/ov/main_bot.html), and 
World View from Intervista (http://www.intervista.com/ 
products/wo rid view/index, html), These plug-ins can typi- 
cally be downloaded for free from the Web. 

25 VRML is capable of displaying static and animated 
objects and supports hyperlinks to multimedia formats such 
as audio clips, video files, and graphical images. As users 
maneuver through VRML worlds, the landscape shifts to 
match their movements and give the impression that they are 

30 moving through real space. The new VRML 2.0 specifica- 
tion finalized in August 1996 intensifies the immersive 
experience of VR worlds on the Web by enabling users to 
interact both with each other and with their surroundings. 
Other new features supported by VRML 2.0 include richer 

35 geometry description, background textures, sound and 
video, multilingual text, Java applets, and scripting using 
VBScript and JavaScript. VRML will become a significant 
technology in creating next-generation Internet application 
as the language continues to mature and its availability 

40 increases. 

The Future: Give Us a Big SMIL 

The Web has come a long way since the codification of 
HTML 1.0. It has moved from simple text-based documents 
that included headings, bulk ted lists, and hyperlinks to 

45 dynamic pages that support rich graphic images and virtual 
reality. So what next for the Web? The answer resides in a 
Synchronized Multimedia Integration Language (SMIL), a 
new markup language being developed by the W3C. SMIL 
will allow Web authors to deliver television-like content 

50 over the Web using less bandwidth and a simple text editor, 
rather than intricate scripting. 

SMIL is based on XML and does not represent a specific 
media format. Instead, SMIL defines the tags that link 
different media types together. The language enables Web 

55 authors to sort multimedia content into separate audio, 
video, text, and image files and streams which are sent to a 
user's browser. The SMIL tags then specify the "schedule" 
for displaying those components by determining whether 
they should be played together or sequentially. This enables 

60 elaborate multimedia presentations to be created out of 
smaller, less bandwidth-consuming components. 
Implemenation Considerations 

Many features such as graphics, frames, etc. supported by 
Web Browsers today were not available in initial releases. 

65 Furthermore, with every new release the functionality sup- 
ported by Web Browsers keeps growing at a remarkable 
pace. 
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Much of the appeal of Web Browsers is the ability to 
provide a universal client that will offer users a consistent 
and familiar user interface from which many types of 
applications can be executed and many types of documents 
can be viewed, on many types of operating systems and 
machines, as well as independent of where these applica- 
tions and documents reside. 

Web Browsers employ standard protocols such as Hyper- 
text Transfer Protocol (HTTP) and File Transfer Protocol 
(FTP) to provide seamless access to documents across 
machine and network boundaries. 

The distinction between the desktop and the Web Browser 
narrowed with the release of Microsoft IE4.0, which inte- 
grated Web browsing into the desktop, and gave a user the 
ability to view directories as though they were Web pages. 
Web Browser, as a distinct entity, may even fade away with 
time. 

Exemplary products that may be used to implement this 
component includes Netscape Navigator; Netscape Commu- 
nicator; Microsoft Internet Explorer; Netscape Live Wire; 
Netscape LiveWirePro; Symantec Visual Cafe; Microsoft 
Front Page; Microsoft Visual J++; IBM VisualAge. 
Execution Products 

Netscape Navigator or Communicator — one of the origi- 
nal Web Browsers, Navigator currently has the largest 
market share of the installed browser market and strong 
developer support. Communicator is the newest version 
with add-on collaborative functionality 
Microsoft Internet Explorer (IE) — a Web Browser that is 
tightly integrated with Windows and supports the major 
features of the Netscape Navigator as well as 
Microsoft's own ActiveX technologies. 
Development Products 

Web Browsers require new or at least revised develop- 
ment tools for working with new languages and standards 
such as HTML, ActiveX and Java. Many browser content 
development tools are available. The following are several 
representative products: 

Netscape Live Wire and Live Wire Pro — visual tool suite 
designed for building and managing complex, dynamic 
Web sites and creating live online applications. 
Symantec Visual Cafe" — the first complete Rapid Appli- 
cation Development (RAD) environment for Java; it 
allows developers to assemble complete Java applets 
and applications from a library of standard and third 
party objects. Visual Cafe also provides an extensive 
set of text based development tools. 
Microsoft FrontPage — Web site management tool that 
supports web page creation, web site creation, page and 
link management and site administration. 
Microsoft Visual J++ — a product similar to Visual C++, 
VJ++ allows the construction of Java and ActiveX 
applications through an integrated graphical develop- 
ment environment. 
IBM VisualAge for Java — a product similar to VisualAge 
for Smalltalk, VJ++ allows the construction of Java 
applications through an integrated graphical develop- 
ment environment. It supports JavaBeans. Used by 
Eagle team for the Eagle JavaBeans reference applica- 
tion. 

Browser Extension 1310 

Browser Extension Services provide support for executing 
different types of applications from within a Browser. These 
applications provide functionality that extend Browser capa- 
bilities. The key Browser Extensions are: 

Plug-in — a term coined by Netscape, a plug-in is a 
software program that is specifically written to be executed 
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within a browser for the purpose of providing additional 
functionality that is not natively supported by the browser, 
such as viewing and playing unique data or media types. 
Typically, to use a plug-in, a user is required to download 

5 and install the Plug-in on his/her client machine. Once the 
Plug-in is installed it is integrated into the Web browser. The 
next time a browser opens a Web page that requires that 
Plug-in to view a specific data format, the browser initiates 
the execution of the Plug-in. Until recently Plug-ins were 

1Q only accessible from the Netscape browser. Now, other 
browsers such as Microsoft's Internet Explorer are begin- 
ning to support Plug-in technology as well. Also, Plug-ins 
written for one browser will generally need to be modified 
to work with other browsers. Plug-ins are also operating 

15 system dependent. Therefore, separate versions of a Plug-in 
may be required to support Windows, Macintosh, and Unix 
platforms. 

Helper Application/Viewer — is a software program that is 
launched from a browser for the purpose of providing 
2Q additional functionality to the browser. The key differences 
between a helper application or sometimes called a viewer 
and a plug-in are: 

How the program is integrated with the Web browser — 
unlike a plug-in, a helper application is not integrated 
25 with the Web Browser, although it is launched from a 
Web browser. A helper application generally runs in its 
own window, contrary to a plug-in which is generally 
integrated into a Web page. 
How the program is installed — like a plug-in, the user 
30 installs the helper application. However, because the 
helper application is not integrated with the browser, 
the user tends to do more work during installation 
specifying additional information needed by the 
browser to launch the helper application. 
35 How the program is initiated — the user tends to initiate 
the launching of the helper application, unlike a plug-in 
where the browser does the initiation. 
From where the program is executed — the same helper 
application can be executed from a variety of browsers 
40 without any updates to the program, unlike a plug-in 
which generally needs to be updated for specific brows- 
ers. However, helper applications are still operating 
system dependent. 
Java applet — a program written in Java that runs within or 
45 is launched from the client's browser. This program is 
loaded into the client device's memory at runtime and then 
unloaded when the application shuts down. A Java applet 
can be as simple as a cool animated object on an HTML 
page, or can be as complex as a complete windows appli- 
50 cation running within the browser. 

ActiveX control — is also a program that can be run within 
a browser, from an application independent of a browser, or 
on its own. ActiveX controls are developed using Microsoft 
standards that define how re-usable software components 
55 should be built. Within the context of a browser, ActiveX 
controls add functionality to Web pages. These controls can 
be written to add new features like dynamic charts, anima- 
tion or audio. 

Implementation Considerations 

60 Viewers and plug-ins are some of the most dynamic 
segments of the browser market due to quickly changing 
technologies and companies. What was yesterday a plug-in 
or a viewer add-on often becomes a built-in capability of the 
browser in its next release. 

65 Exemplary products that may be used to implement this 
component include Real Audio Player; VDOLive; Macro- 
media Shockwave; Internet Phone; Web 3270. 
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Real Audio Player — a plug-in designed to play audio and 
video in real-time on the Internet without requiring to 
download the entire audio file before you can begin 
listening, or a video file before you can begin viewing. 

Macromedia Shockwave — a plug-in used to play back 
complex multimedia documents created using Macro- 
media Director or other products. 

Internet Phone — one of several applications which allow 
two-way voice conversation over the Internet, similar 
to a telephone call. 

Web3270 — a plug-in from Information Builders that 
allows mainframe 3270-based applications to be 
viewed across the Internet from within a browser. The 
Web3270 server provides translation services to trans- 
form a standard 3270 screen into an HTML-based 
form. Interest in Web3270 and similar plug-ins has 
increased with the Internets ability to provide custom- 
ers and trading partners direct access to an organiza- 
tions applications and data. Screen scraping plug-ins 
can bring legacy applications to the Internet or intranet 
very quickly. 
Form 1312 

Like Form Services outside the Web Browser, Form 
Services within the Web Browser enable applications to use 
fields to display and collect data. The only difference is the 
technology used to develop the Forms. The most common 
type of Forms within a browser are Hypertext Markup 
Language (HTML) Forms. The HTML standard includes 
tags for informing a compliant browser that the bracketed 
information is to be displayed as an editable field, a radio 
button, or other form-type control. Currently, HTML brows- 
ers support only the most rudimentary forms — basically 
providing the presentation and collection of data without 
validation or mapping support. When implementing Forms 
with HTML, additional services may be required such as 
client side scripting (e.g., VB Script, JavaScript). 

Additionally Microsoft has introduced ActiveX docu- 
ments which allow Forms such as Word documents, Excel 
spreadsheets, Visual Basic windows to be viewed directly 
from Internet Explorer just like HTML pages. 

Different technologies may be used to create Forms that 
are accessible outside of the browser from those that are 
accessible within the browser. However, with the introduc- 
tion of ActiveX documents these differences are getting 
narrower. 

Exemplary products that may be used to implement this 
component include JetForms JetForm Design; Lotus Forms; 
Visual Basic; Front Page. 

FrontPage — Web site management tool that supports web 
page creation, web site creation, page and link man- 
agement and site administration. 
User Navigation 1314 

Like User Navigation Services outside the Web Browser, 
User Navigation Services within the Web Browser provide 
a user with a way to access or navigate between functions 
within or across applications. These User Navigation Ser- 
vices can be subdivided into three categories: 

Hyperlink — the Internet has popularized the use of under- 
lined key words, icons and pictures that act as links to 
further pages. The hyperlink mechanism is not con- 
strained to a menu, but can be used anywhere within a 
page or document to provide the user with navigation 
options. It can take a user to another location within the 
same document or a different document altogether, or 
even a different server or company for that matter. 
Hie re are three types of hyperlinks: 
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Hypertext is very similar to the concept of Context 
Sensitive Help in Windows, where the reader can 
move from one topic to another by selecting a 
highlighted word or phrase. 
s Icon is similar to the hypertext menu above, but selec- 
tions are represented as a series of icons. The HTML 
standard and popular browsers provide hyperlinking 
services for non-text items such as graphics. 

Image Map is also similar to the hypertext menu above, 
but selections are represented as a series of pictures. 
A further evolution of the image map menu is to 
display an image depicting some place or thing (e.g., 
a picture of a bank branch with tellers and loan 
officers). 

Customized Menu — a menu bar with associated pull- 
15 down menus or context-sensitive pop-up menus. 
However, as mentioned earlier this method hides func- 
tions and options within menus and is difficult for 
infrequent users. Therefore, it is rarely used directly in 
HTML pages, Java applets or ActiveX controls. 
20 However, this capability might be more applicable for 
intranet environments where the browsers themselves 
need to be customized (e.g., adding custom pull -down 
menus within Internet Explorer) for the organizations 
specific business applications. 
25 Virtual Reality — A virtual reality or a virtual environment 
interface takes the idea of an image map to the next 
level by creating a 3-dimensional (3-D) environment 
for the user to walk around in. Popularized by PC 
games like Doom, the virtual environment interface can 
30 be used for business applications. Imagine walking 
through a shopping mall and into and around virtual 
stores, or flying around a 3-D virtual resort complex 
you are considering for a holiday. 
To create sophisticated user navigation interfaces such as 
35 these requires additional architectural services and lan- 
guages. The Virtual Reality Modeling Language (VRML) is 
one such language gaining in popularity. 
Implementation Considerations 
The hyperlink metaphor makes it possible for the user to 
40 jump from topic to topic instead of reading the document 
from beginning to end. For many types of applications, this 
can create a more user-friendly interface, enabling the user 
to find information faster. 
An image map menu can be useful where all users share 
45 some visual model for how business is conducted, and can 
be very engaging, but also painfully slow if even a moderate 
speed communications connection is required. Additional 
Image Map Services are required to map the location of user 
mouse clicks within the image to the corresponding page or 
50 window which is to be launched. 

Exemplary products that may be used to implement this 
component include Silicon Graphics Open Inventor; 
VREAM VRCreator; DimensionX Liquid Reality. 
There are many toolkits and code libraries available to 
S5 speed development of applications utilizing Reality services. 
Below are some representative products: 
Silicon Graphics Open Inventor — an object-oriented 3-D 
toolkit used to build interactive 3-D graphics using 
objects such as cameras, lights and 3-D viewers; pro- 
6 q vides a simple event model and animation engine. 
VREAM VRCreator — a toolkit for building interactive 
virtual reality environments; supports gravity, 
elasticity, and throw-ability of objects, textured and 
colored 3-D objects and construction of networked 
65 multi -participant worlds. Provides support for ActiveX. 
DimensionX Liquid Reality — VRML 2.0 platform writ- 
ten in Java, which provides both a viewer for viewing 
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VRML content and a toolkit of Java classes for creating 
powerful 3-D applications. It supports more than 250 
classes for 3-D content creation. 

Report and Print 1316 

Report and Print Services support the creation and 

on-screen previewing of paper or photographic documents 

which contain screen data, application data, graphics or 

images. 

Implementation Considerations 

Printing services must take into consideration varying 
print scenarios common in Netcentric environments, includ- 
ing: varying graphics/file types (Adobe .PDF, .GIF, JPEG), 
page margins and breaks, HTML constructs including tables 
and frames, headers/titles, extended character set support, 
etc. 

Is there a need for reporting or decision support? 

Use report writers when you need to transform user data 
into columnar reports, forms, or mailing lists that may 
require sophisticated sorting and formatting facilities. This 
generally occurs for two reasons. The first is building 
"production reports" (i.e., reports that are built once and then 
used repeatedly, generally on a daily/weekly/monthly basis). 
The second is ad hoc reporting and decision support. Prod- 
ucts targeted at one or the other use will have different 
facilities, (source is market research) 
Is there a need to ease access to corporate data? 

Use report writers when users require easy and quick 
access to corporate data. Since developers can deliver 
reports as run-time applications, users are shielded from 
having to learn complicated databases in order to access 
information. All a user has to do to retrieve the data is click 
on an icon to launch a report. Because these run-time 
applications are smaller than normal applications, they 
launch faster and require very little training to operate, 
(source is market research) 
Product Considerations 
Buy vs. Build 

There are numerous packaged controls on the market 
today that support basic report and print capability. 
However, a careful evaluation of both functions and features 
and vendor viability must be completed before a decision 
can be made. Architects must additionally be sure to evalu- 
ate that controls will support all required environments, are 
small in size and extensible as requirements demand. 
How important is performance? 

In general, performance of data access and printing should 
be considered. Some typical benchmark tests include table 
scan, single -table report, joined table report, and mailing 
label generation times, (source is market research) 
What is the budget? 

Per developer costs as well as run time licensing fees, 
maintenance costs, support fees, and upgrade charges should 
be considered. 

Do I have another component that satisfies this requirement? 

Many databases and application development tools are 
shipped with built in or add-on report writing capability. 
However, stand-alone report writers: (1) are more powerful 
and flexible, especially when dealing with multiple data 
sources and a wide variety of formats; (2) can retrieve 
information from more data sources than the bundled report 
writers and can create reports from several data sources 
simultaneously; (3) excel in ease of use, both in designing 
and generating reports; (4) offer better tools and more 
predefined reports; and (5) have faster engines, (source is 
market research) 
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Does the product integrate with the existing or proposed 
architecture? 

It is important to consider how well a product integrates 
with desktop tools (word processing, spreadsheet, graphics 
5 etc.) and application development programs. These items 
can be used to extend the capabilities of the reporting 
package. 

What databases does the product support? 

A product should support the most widely used PC file 
formats and Client/Server databases. It may be necessary to 
consider the type of support. For example, native database 
interfaces tend to have better performance than open stan- 
dards such as ODBC. Another possible consideration is how 
well the product accesses multiple files or databases, (source 
is market research) 
15 What are the required features of the tool? 

Features to look for include but are not limited to: 

WYSIWYG print preview 

Ability to create views — prevents users from getting 
overwhelmed with choices when selecting a table, acts 
20 as a security system by controlling which users have 
access to certain data, and increases performance since 
only the data users need gets downloaded to the report 
engine, thereby reducing network traffic. 
Data dictionary — store predefined views, formats, and 
25 table and field name aliases 
User friendly query tool 
Scripting or macro language 
Supported data types and formats 
30 Formatting capabilities (page orientation, fonts, colors, 
margins, condensed printing, etc.) 
Supported report types 
Aggregate functions. 
Is the intention to create production reports or facilitate end 
35 user queries? 

Ease of use will be of major importance for end user query 
and decision support type applications. In contrast, func- 
tionality that allows for the implementation of complex 
reporting requirements will outweigh ease of use for appli- 
40 cations whose objective is creating production reports. 
Direct Manipulation 1318 

Direct Manipulation Services enable applications to pro- 
vide a direct manipulation interface (often called "drag & 
drop"). A direct manipulation interface allows users to 
45 manage multiple "application objects" by manipulating 
visual representations of those objects. For example, a user 
may sell stock by dragging "stock" icons out of a "portfolio" 
icon and onto a "trading floor" icon. Direct Manipulation 
Services can be further divided as follows: 
50 Display: These services enable applications to represent 
application objects as icons and control the display 
characteristics (color, location, etc.) of these icons. 
Input/Validation: These services enable applications to 
invoke validation or processing logic when an end user 
55 "acts on" an application object. "Acting on" an object 
may include single clicking, double clicking, dragging, 
or sizing. 
Input Device 1320 

Detect user input from a variety of input technologies (i.e. 
60 pen based, voice recognition, touch-screen, mouse, digital 
camera, etc.). 

Implementation Considerations 

Voice response systems are used to provide prompts and 
responses to users through the use of phones. Voice response 
65 systems have scripted call flows which guide a caller 
through a series of questions. Based on the users key pad 
response, the voice response system can execute simple 
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calculations, make database calls, call a mainframe legacy ucts are designed to offer open, industrial strength database 

application or call out to a custom C routine. Leading voice management for decision support, transaction processing 

response system vendors include VoiceTek and Periphonics. and line of business applications. The DB2 family now 

Voice recognition systems are becoming more popular in spans not only IBM platforms like personal computers, 

conjunction with voice response systems. Users are able to 5 AS/400 systems, RISC System/6000 hardware and IBM 

speak into the phone in addition to using a keypad. Voice mainframe computers, but also non-IBM machines such as 

recognition can be extremely powerful technology in cases Hewlett-Packard and Sun Microsystems. Microsoft SQL 

where a key pad entry would be limiting (e.g., date/time or Server— the latest version of a high-performance client/ 

location). Sophisticated voice recognition systems have ^ r relational database management system. Building on 

been built which support speaker-independence, continuous 10 ver ? l0n 60 ' SQL Sen ?. r 6 f ^uces key new features 

speech and large vocabularies. S * ch as t "™P m * *f ributed transactions, simplified 

r & administration, OLE-based programming interfaces, 

Information 1002,1004 improved support for industry standards and Internet inte- 

FIG. 14 illustrates several components of the Information |^Stioi^yiichromatiQn 1404 
Services of the present invention. Information Services , 5 Replication Services support an environment in which 
manage electronic data assets and enable applications to muUiple copies of databases must 5e ma iotained. For 
access and manipulate data stored locally or remotely in example, if ad hoc reporting queries or data warehousing 
documents or databases. They minimize an application's applications can work with a replica of the transaction 
dependence on the physical storage and location within the database, these resource intensive applications will not inter- 
network. Information Services can be grouped into two 20 fere with mission critical transaction processing. Replication 
categories: Database Services, and Document Services can be either complete or partial. During complete replica- 
Database Services 1402 tion all records are copied from one destination to another, 

Database Services are responsible for providing access to while during partial replication, only a subset of data is 

a local or a remote database, maintaining integrity of the copied, as specified by the user or the program. Replication 

data within the database and supporting the ability to store 25 can be done either real-time or on-demand (i.e., initiated 

data on either a single physical platform, or in some cases DV a user, program or a scheduler). The following might be 

across multiple platforms. These services are typically pro- possible if databases are replicated on alternate servers): 

vided by DBMS vendors and accessed via embedded or better availability or recoverability of distributed applica- 

call-level SQL variants and supersets. Depending upon the tions i better performance and reduced network cost, particu- 

underlying storage model, non-SQL access methods may be 30 l f rly m ™™ 0QmQnis > where users are widely geographically 

used instead. dispersed; etc 

Many of the Netcentric applications are broadcast-type Synchronization Services perform the transactions 

, . , 4 r * t « required to make one or more information sources that are 

applications, designed to market products and/or publish lQ mirror each other consistent Th is may 

pohaes and procedures. Furthermore, mere !s now a growth especially valuable whea implementing applications for 

of Netcentnc applications that are transaction -type appkea- 35 users 0 f mobile devices because it allows a working copy of 

tions used to process a customers sales order, maintenance data or documents to be available locally without a constant 

request, etc. Topically these type of applications require network attachment. The emergence of applications that 

integration with a database manager. Database Services allow teams to collaborate and share knowledge has height - 

include: Storage Services, Indexing Services, Security ened the need for Synchronization Services in the execution 

Services, Access Services, and Replication/Synchronization 40 architecture. 

Services The terms Replication and Synchronization are used 

Implementation Considerations interchangeably, depending on the vendor, article, book, etc. 

The core database services such as Security, Storage and For example, when Lotus Notes refers to Replication, it 
Access are provided by all major RDBMS products, means both a combination of Replication and Synchroniza- 
whereas the additional services of Synchronization and 45 tion Services described above. When Sybase refers to Rep- 
Replication are available only in specific products. lication it only means copying data from one source to 
Product Considerations another. 

Oracle 7.3; Sybase SQL Server; Informix; IBM DB/2; Implementation Consideration 
Microsoft SQL Server Replication/Synchronization Services are sometimes sup- 
Oracle 7.3 — market leader in the Unix client/server 50 plied as part of commercial databases, document manage- 
RDBMS market, Oracle is available for a wide variety ment systems or groupware products such as Lotus Notes, 
of hardware platforms including MPP machines. Microsoft Exchange, Oracle, etc. 

Oracles market position and breadth of platform sup- With Windows 95 and Windows NT 4.0, Microsoft has 

port has made it the RDBMS of choice for variety of also introduced the concept of Replication/Synchronization 

financial, accounting, human resources, and manufac- 55 Services into the operating system. Through the briefcase 

turing application software packages. Informix — application users can automatically synchronize files and 

second in RDBMS market share after Oracle, Informix SQL data between their Windows PC and a Windows NT 

is often selected for its ability to support both large server. Underlying this application is the user-extensible 

centralized databases and distributed environments Win32 synchronization services API which can be used to 

with a single RDBMS product, Sybase SQL Server — 60 build custom synchronization tools, 

third in RDBMS market share, Sybase traditionally Are changes in data usage anticipated? 

focused upon medium-sized databases and distributed Data can be dynamically changed to accommodate 

environments; it has strong architecture support for changes in how the data is used. 

database replication and distributed transaction pro- Is it desirable to shield the user from the data access process? 

cessing across remote sites. 65 A replicated database often consolidates data from het- 

IBM DB2 — the leader in MVS mainframe database erogeneous data sources, thus shielding the user from the 

management, IBM DB2 family of relational database prod- processes required to locate, access and query the data. 
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What are the availability requirements of the system? 

Replication provides high availability. If the master data- 
base is down, users can still access the local copy of the 
database. 

Is there a business need to reduce communication costs? 

Depending on the configuration (real time vs. nightly 
replication, etc.), there is a potential to reduce communica- 
tions costs since the data access is local. 
Is scalability an issue? 

With users, data, and queries spread across multiple 
computers, scalability is less of a problem. 
Can users benefit from the increased performance of local 
data access? 

Access to replicated data is fast since data is stored locally 
and users do not have to remotely access the master data- 
base. This is especially true for image and document data 
which cannot be quickly accessed from a central site. 
Making automatic copies of a database reduces locking 
conflicts and gives multiple sets of users better performance 
than if they shared the same database. 
Product Considerations 

What is the current or proposed environment? 

Platforms supported as well as source and target DBMS 
should be considered. 
What are the technical requirements? 

Products differ in features such as complete refresh vs. 
differential refresh (replication of changes), replication 
granularity (row, table, database), method of capturing 
changes (snapshot, SQL statement intercept, trigger-based, 
log-based), method of propagating copies (push, pull), 
propagation timing controls (database event-driven, sched- 
uled based on interval, scheduled based on application 
event-driven, manually invoked), and conflict resolution 
mechanisms. Also important is what management utilities 
are available with the product. 
Are available resources and issue? 

Products vary in the amount of resources required to 
install and operate the system. 
What are the business requirements? 

Three key considerations are: 

Who owns and uses the data? Replication products sup- 
port one or more of the three ownership models: 
Primary site ownership — data is owned by one site; 
Dynamic site ownership) — data owned by one site, 
however site location can change; and Shared site 
ownership — data ownership is shared by multiple sites. 

Which of the four basic types of replication style is 
appropriate? The four styles are: Data dissemination — 
portions of centrally maintained data are replicated to 
the appropriate remote sites; Data consolidation — data 
is replicated from local sites to a central site where all 
local site data is consolidated; Replication of logical 
partitions — replication of partitioned data; and Update 
anywhere — multiple remote sites can possible update 
same data at same time. 

What is the acceptable latency period (amount of time the 
primary and target data can be out of synch)? There are 
three basic replication styles depending on the amount 
of latency that is acceptable: Synchronous — real-time 
access for all sites (no latency); Asynchronous near 
real-time — short period of latency for target sites; 
Asynchronous batch/periodic — predetermined period 
of latency for all sites. 
Do I already have a component that satisfies this criteria? 

Many DBMS vendors ship replication products as either 
part of the base package or as an additional feature. 
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Possible Product Options 

Sybase Replication Server; Oracle Symmetric Replica- 
tion; CA-Ingres Replicator; InfoPump; DataPropagator 
Relational; Informix Replicator 
5 Access 1408 

Access Services enable an application to retrieve data 
from a database as well as manipulate (insert, update, delete) 
data in a database. SQL is the primary approach for access- 
ing records in today's database management systems. 
Q Client-server systems often require data access from 
multiple databases offered by different vendors. This is often 
due to integration of new systems with existing legacy 
systems. The key architectural concern is in building the 
application where the multi-vendor problem is transparent to 
the client. This provides future portability, flexibility and 
35 also makes it easier for application developers to write to a 
single database access interface. Achieving database access 
transparency requires the following: 
Standards Based SQL API — this approaches uses a single, 
standards based set of APIs to access any database, and 
20 includes the following technologies: Open Database 
Connectivity (ODBC), Java Database Connectivity 
(JDBC), and Object Linking and Embedding (OLE 
DB). 

SQL Gateways provide a mechanism for clients to trans- 
25 parently access data in a variety of databases (e.g., 
Oracle, Sybase, DB2), by translating SQL calls written 
using the format and protocols of the gateway server or 
primary server to the format and protocols of the target 
database. Currently there are three contending archi- 
30 tectures for providing gateway functions: 

Distributed Relational Data Access (DRDA) is a standard 
promoted by IBM for distributed data access between 
heterogeneous databases. In this case the conversion of 
the format and protocols occurs only once. It supports 
SQL89 and a subset of SQL92 standard and is built on 
top on APPC/APPN and TCP/IP transport stacks. 
IBI's EDA/SQL and the Sybase /MDI Open Server use 
SQL to access relational and non-relational database 
systems. They use API/SQL or T-SQL respectively as 
the standard interface language. A large number of 
40 communication protocols are supported including 
NetBIOS, SNA, DecNET, TCP/IP. The main engine 
translates the client requests into specific server calls. It 
handles security, authentication, statistics gathering and 
some system management tasks. 
45 Implementation Considerations 

Gateways may create bottlenecks, because all the clients 
go through a single gateway. 
Security 1410 

Security Services enforce access control to ensure that 

50 records are only visible or editable by authorized people for 
approved purposes. Most database management systems 
provide access control at the database, table, or row level as 
well as concurrency control. 
Implementation Considerations 

55 Will the application be used in a distributed environment? 
In a distributed environment, the need exists to provide 
access to the corporate data and resources in a secure and 
controlled manner. This access depends on the role of the 
user, the user group, etc. within that environment. Since 

60 security is an architecture component where functionality 
and robustness vary across engagements, the architectures 
usually provide a base set of security functions. These 
functions target securing the systems corporate data and 
resources, as opposed to securing an applications detailed 

65 functions. 

The security component prevents unauthorized users from 
accessing corporate data/resources by providing the users 
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with access codes — password & ID — that allows the user to 
login to the system or execute any (or a particular) appli- 
cation. 

Security components can restrict access to functions 
within an application based on a users security level. The 
highest level security is whether the user has access to run 
the application. The next level checks if the user has access 
to functions within the application, such as service calls or 
windows. At an even lower level, the security component 
could check security on more granular functions, such as 
widgets on a window. 

Security usually resides on both the client and server 
platform in a distributed environment. True security should 
always be placed on the server platform, to protect the 
system through access outside of a client application. 
Is there a direct/indirect relationship between the user role/ 
group and the data/services? 

There are situations where it is required for the system to 
maintain the relationship of the users role and the users 
access to specific system services/resources. For example, a 
database administrator will have read-write-delete access to 
the database, whereas a sales manager will have only read 
access to it for viewing the data in various forms. The 
security component should provide the functionality for 
validating the users resource access privileges based on the 
role of the user. 
Indexing 1412 

Indexing Services provide a mechanism for speeding up 
data retrieval. In relational databases one or more fields can 
be used to construct the index. So when a user searches for 
a specific record, rather than scanning the whole table 
sequentially the index is used to find the location of that 
record faster. 
Storage 1414 

Storage Services manage data physical storage. These 
services provide a mechanism for saving information so that 
data will live beyond program execution. Data is often 
stored in relational format (an RDBMS) but may also be 
stored in an object-oriented format (OODBMS) or other 
formats such as IMS, VSAM, etc. 
Document Services 1416 

Document Services provide similar structure and control 
for documents that database management systems apply to 
record oriented data. A document is defined as a collection 
of objects potentially of different types (e.g., structured data, 
unstructured data, images, multi-media) a business user 
deals with. An individual document might be a table created 
using a spreadsheet package such as Microsoft Excel, a 
report created using a word processing package such as 
Lotus AmiPro, a Web page created using an HTML author- 
ing tool, unstructured text or a combination of these object 
types. Regardless of the software used to create and maintain 
the component parts, all parts together constitute the 
document, which is managed as a single entity. 

Netcentric applications that are executed from a browser 
are particularly well suited for serving up document style 
information. If the Web application consists of more than 
just a few HTML documents, integration with a document 
management system should be considered. Document Ser- 
vices include: Storage Services, Indexing Services, Security 
Services, Access Services, Replication/Synchronization 
Services, and Versioning Services 
Possible Product Options 
Documentum Server; Saros; PC Docs 

Documentum — Documentum Enterprise Document Man- 
agement System (EDMS) automates and accelerates 
the creation, modification, and reuse of business- 
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critical documents, Web pages, and other unstructured 
data and all of the collaborative efforts involved. 
Saros — Saros Discovery Suite is the next generation 
client/server solution that integrates Saros Document 
5 Manager, FileNet Ensemble and Watermark Client to 
provide powerful, tightly-integrated electronic docu- 
ment management, workflow, and document-imaging 
capabilities. 
Versioning 1418 
10 Versioning Services maintain a historical record of the 
changes to a document over time. By maintaining this 
record, these services allow for the re-creation of a docu- 
ment as it looked at any given point in time during it's 
evolution. Additional key versioning features record who 
15 made changes when and why they were made. 
Replication/Synchronization 1404 

Replication Services support an environment in which 
multiple copies of documents must be maintained. A key 
objective is that documents should be shareable and search- 
20 able across the entire organization. Therefore, the architec- 
ture needs to provide logically a single repository, even 
though the documents are physically stored in different 
locations. The following might be possible if documents are 
replicated on alternative server(s): better availability or 
25 recoverability of a distributed application; better perfor- 
mance; reduced network cost; etc. 

Synchronization Services perform the transactions 
required to make one or more information sources that are 
intended to mirror each other consistent. They support the 
30 needs of intermittently connected users or sites. Just like for 
databases, these services are especially valuable for users of 
mobile devices that need be able to work locally without a 
constant network connection and then be able to synchronize 
with the central server at a given point in time. 
Implementation Considerations 

Products such as Lotus Notes and Microsoft Exchange 
allow remote users to replicate documents between a client 
machine and a central server, so that the users can work 
4Q disconnected from the network. When reattached to the 
network, users perform an update that automatically 
exchanges information on new, modified and deleted docu- 
ments. 

Note: Both Lotus Notes and MS Exchange provide a 
45 limited subset of the Document Services described in this 
section. This should be carefully evaluated when consider- 
ing these products to provide document management ser- 
vices. 

Access 1408 

50 Access Services support document creation, maintenance 
and retrieval. These services allow users to capture knowl- 
edge or content through the creation of unstructured 
information, i.e. documents. Access Services allow users to 
effectively retrieve documents that were created by them and 

55 documents that were created by others. Documents can be 
comprised of many different data types, including text, 
charts, graphics, or even audio and video. 
Security 1410 

Documents should be accessed exclusively through the 
60 document management backbone. If a document is checked- 
in, check-out, routed, viewed, annotated, archived, or 
printed it should be done only by users with the correct 
security privileges. Those access privileges should be able to 
be controlled by user, role, and group. Analogous to record 
65 locking to prevent two users from editing the same data, 
document management access control services include 
check-in/check-out services to limit concurrent editing. 
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Indexing 1412 

Locating documents and content within documents is a 
more complex problem and involves several alternative 
methods. The Windows file manager is a simplistic imple- 
mentation of a hierarchical organization of files and collec- 
tion of files. If the user model of where documents should be 
stored and found can be represented in this way, the use of 
structure and naming standards can be sufficient. However, 
a hierarchical document filing organization is not suitable 
for many types of document queries (e.g., retrieving all sales 
order documents for over $1,000). 

Therefore, most document management products provide 
index services that support the following methods for 
searching document repositories: 

Attribute Search — scans short lists (attributes) of impor- 
tant words that are associated with a document and 
returns documents that match the search criteria. For 
example, a user may query for documents written by a 
specific author or created on a particular date. Attribute 
search brings the capabilities of the SQL-oriented data- 
base approach to finding documents by storing in a 
database the values of specially identified fields within 
a document and a reference to the actual document 
itself. In order to support Attribute Search an index 
maintains documents' attributes, which it uses 
to-manage, find and catalog documents. This is the 
least complicated approach of the searching methods. 
Full -text Search — searches repository contents for exact 
words or phrases and returns documents that match the 
search criteria. In order to facilitate Full-text Search, 
full-text indexes are constructed by scanning docu- 
ments once and recording in an index file which words 
occur in which documents. Leading document manage- 
ment systems have full-text services built-in, which can 
be integrated directly into applications. 
Context Search — searches repository contents for exact 
words or phrases. Also, searches for related words or 
phrases by using synonyms and word taxonomies. For 
example, if the user searches for auto, the search engine 
should look for car, automobile, motor vehicle, etc. 
Boolean Search — searches repository contents for words 
or phases that are joined together using boolean opera- 
tors (e.g., AND, OR, NOT). Same type of indexes are 
used for Boolean Search as for Full-Text Search. 
The following products are used to index and search Web 
and non-Web documents: 

Verity Topic — delivers accurate indexing, searching and 
filtering of a wide variety of information sources and 
formats. Verity Topic is integrated directly into several 
document management products, allowing systems to 
full-text index its unstructured information. Verity 
Topic also offers a variety of products to help full-text 
index Web sites. 
Fulcrum — provides a variety of robust, multi-platform 
indexing and retrieval products that deliver full- 
function text retrieval capabilities. Fulcrums products 
are typically integrated with custom databases, Web 
sites and document management systems. 
The following products are mainly used for Web docu- 
ments: 

Microsoft Index Server 1.1 — allows for search of Web 
documents, including Microsoft Word and Microsoft 
Excel. It works with Windows NT Server 4.0 and 
Internet Information Server 2.0 or higher to provide 
access to documents stored on an intranet or Internet 
site. Index Server supports full -text searches and 
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retrieves all types of information from the Web browser 
including HTML, text, and all Microsoft Office 
documents, in their original format. 
Netscape Catalog Server 1.0 — provides an automated 

5 search and discovery server for creating, managing, and 
keeping current an online catalog of documents resid- 
ing on corporate intranets and the Internet. Catalog 
Server offers query by full text, category, or attributes 
such as title, author, date, etc. It also supports multiple 

10 file formats, including HTML, Word, Excel, 
PowerPoint, and PDF. 
Storage 1414 

Storage Services manage the document physical storage. 
Most document management products store documents as 

is objects that include two basic data types: attributes and 
content. Document attributes are key fields used to identify 
the document, such as author name, created date, etc. 
Document content refers to the actual unstructured informa- 
tion stored within the document. Generally, the documents 

20 are stored in a repository using one of the following meth- 
ods: 

Proprietary database — documents (attributes and 
contents) are stored in a proprietary database (one that 
the vendor has specifically developed for use with their 

25 product). 

Industry standard database — documents (attributes and 
contents) are stored in an industry standard database 
such as Oracle or Sybase. Attributes are stored within 
traditional database data types (e.g., integer, character, 
etc.); contents are stored in the database's BLOB 
(Binary Large Objects) data type. 
Industry standard database and file system — Documents' 
attributes are stored in an industry standard database, 

35 and documents' contents are usually stored in the 
file-system of the host operating system. Most docu- 
ment management products use this document storage 
method, because today, this approach provides the most 
flexibility in terms of data distribution and also allows 

40 for greater scalability. 

Communication 1006,1008 

As illustrated in FIG. 15, Network services provided by 
the Communications Services layer are grouped into four 
4S major categories of functionality: Virtual Resource, 
Directory, Messaging, and Security services 1502,1504, 
1506,1508. 

Virtual Resource services proxy or mimic the capabilities 
of specialized, network connected resources. This allows a 

50 generic network node to emulate a specialized physical 
device. In this way, network users can interface with a 
variety of specialized resources. 

Directory services play a key role in network architectures 
because of their ability to unify and manage distributed 

55 environments. Managing information about network 
resources involves a variety of processes ranging from 
simple name/address resolution to the logical integration of 
heterogeneous systems to create a common view of services, 
security, etc. 

60 Messaging services transfer formatted information from 
one process to another. These services shield applications 
from the complexity of the network transport services. 

Call centers and customer service centers are integral 
parts of many business operations. Call centers have 

65 enhanced business processes by managing telephone contact 
with potential customers, with the objective of improving 
the Quality of Service (QoS). Several customer and business 
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drivers are motivating a transition from traditional cost- 
based call centers to more strategic centers focused on 
customer interaction. 

Communications Security services control access to 
network-attached resources. Combining network Security 
services with security services in other parts of the system 
architecture (e.g., application and database layers) results in 
robust security. 

Implementation Considerations 
Is data translation required? 

Communications middleware can translate data into a 
format that is compatible with the receiving process. This 
may be required in a heterogeneous environment. An 
example is data translation from ASCII-to-EBCDIC. It is 
important to note that data translation may not be provided 
by all middleware products. 
Are additional communications services required? 

Communications middleware can provide additional 
communications services that may be required by the appli- 
cations. Additional services include dynamic message 
routing, guaranteed delivery, broadcasting, queuing, and 
priority delivery. These common services are usually pro- 
vided in the communications middleware rather than 
addressing them in each application separately. Different 
communications middleware products provide different ser- 
vices. Additionally, many middleware packages, such as 
Tuxedo, provide OLTP functionality. 
Is a packaged middleware solution desired? 

Depending on the functionality required, communications 
middleware can be very complex to custom develop. In 
addition, products have evolved to a point where proven 
solutions exist. Based on this, it can be desirable to buy 
communications middleware rather than to build it. Consid- 
erations of time, budget, skills, and maintenance should be 
taken into account when selecting between a packaged 
middleware product and custom developed middleware. In 
some instances, custom developed middleware may still be 
preferred. 

What is the clients middleware direction? 

There is a definite functionality overlap between commu- 
nications middleware and several other middleware compo- 
nents such as transaction services and information access. In 
addition, communications middleware may be provided by 
various CASE tools. An example of this is the Distribution 
Services component of FCP. Because of this overlap, it is 
important to understand the clients overall direction toward 
middleware and the specific middleware functionality 
required by the overall solution. 
Is a simplified developers interface important? 

The simplified interface associated with communications 
middleware can help to reduce the complexity of developing 
Netcentric applications. The simplified interface helps 
reduce the development complexity by insulating the busi- 
ness applications from the network protocols. Because of 
this, application developers do not need to understand the 
intricacies and somewhat cryptic APIs associated with net- 
work transport protocols. 
Is location transparency required? 

Communication middleware allows the client application 
to access any service on any physical server in the network 
without needing to know where it is physically located. This 
capability may be required in an environment with many 
physical servers or in an environment that is very dynamic. 
It is important to note that location transparency may not be 
provided by all middleware products. 
Does the application need to run on multiple platforms? 

Communications middleware is designed to allow appli- 
cations to access various transport protocols from various 
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vendors. From a network interface perspective, it should be 
easier to port an application from one computing platform to 
another if the application is using communications middle- 
ware. Of course, other porting issues will need to be con- 

5 sidered. 

Virtual Resources 1502 

Virtual Resource services proxy or mimic the capabilities 
of specialized, network-connected resources. This allows a 
generic network node to emulate a specialized physical 

3 q device. In this way, network users can interface with a 
variety of specialized resources. An examples of a Virtual 
Resource service is the capability to print to a network 
printer as if it were directly attached to a workstation. 
Fax 1510 

15 Fax Services provide for the management of both 
in-bound and out-bound fax transmissions. If fax is used as 
a medium for communicating with customers or remote 
employees, in-bound fax services may be required for cen- 
trally receiving and electronically routing faxes to the 

2Q intended recipient. Out-bound fax services can be as simple 
as supporting the sharing on the network of a single fax 
machine or group of machines for sending faxes. 

Fax services can provide centrally managed faxing 
capabilities, thus eliminating the need for fax modems on 

25 every workstation. A fax server generally provides Fax 
services to clients, such as receiving, queuing, and distrib- 
uting incoming faxes and queuing and sending outgoing 
faxes. Clients can view faxes and generate faxes to be sent. 
Applications may compose and transfer faxes as part of 

30 notifying users or delivering information. For example, an 
application may use Fax services to add customer-specific 
information to a delivery receipt form and fax the form to a 
customer. 

Implementation Considerations 
35 More sophisticated out -bound fax architecture services 
are required for supporting fax-back applications. Fax-back 
applications, when coupled with Computer Telephone Inte- 
gration (CTI) are popular for automating customer requests 
for product or service information to be faxed to them. 
Possible Product Options 

Cheyenne Softwares Faxserve; Lotus Fax Server for 
Lotus Notes; Sirens Siren Fax 

The following are examples of fax servers: 
The Lotus® Fax Server (LFS) — provides fax services to 
45 users working on a network running NotcsMail®. In 
addition to combining outgoing and incoming fax capa- 
bilities in a single product, the LFS provides additional 
features, such as automatic routing, and print-to-fax 
driver software that extends fax capabilities to any 
50 Windows-based Notes client. The LFS supports a wide 
variety of fax modems, fax cards and fax file formats 
through the incorporation of device technologies from 
Optus Software, Inc. 
Cheyenne Software's Faxserve 
55 The following is an example of a product that allows 
applications to generate faxes: 

Siren's Siren Fax 
File Sharing 1512 

FIG. 16 illustrates File Sharing services 1512. File Shar- 
60 ing services allow users to view, manage, read, and write 
files that may be located on a variety of platforms in a variety 
of locations. File Sharing services enable a unified view of 
independent file systems. This is represented in FIG. 16, 
which shows how a client can perceive remote files as being 
65 local. 

File Sharing services can provide the following capabili- 
ties: 
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Transparent access — access to remote files as if they were 
local 

Multi-user access — distribution and synchronization of 
files among multiple users, including file locking to 
manage access requests by multiple users 5 

File access control — use of Security services (user 
authentication and authorization) to manage file system 
security 

Multi-platform access — access to files located on various 1Q 
platforms (e.g., UNIX, NT, etc.) 

Integrated file directory — a logical directory structure that 
combines all accessible file directories, regardless of 
the physical directory structure 

Fault tolerance — use of primary and replica file servers to is 
ensure high availability of file system 

Scalability — ability to integrate networks and distributed 
file systems of various sizes 
Possible Product Options 

Novell's NetWare/IntranetWare; Microsoft's Windows 20 
NT Server; Sun Microsystems NFS and Web NFS; Novell's 
IntranetWare NFS Services; IBM/Transarcs Distribute File 
System (DFS); Transarc's AFS 

The following are examples of File Sharing products: 

Novell's NetWare/IntranetWare — Novell's NetWare net- 25 
work operating system includes distributed file 
services, supported by the NetWare Core Protocol 
(NCP). NetWare Directory Services (NDS) manages 
naming and security for files on distributed platforms. 

Microsoft's Windows NT Server 30 

Server Message Block (SMB) — native file -sharing pro- 
tocol in Windows 95, Windows NT, and OS/2. 

Common Internet File System (CIFS) — an enhancement 
to SMB for distributed file systems in a TCP/IP envi- 35 
ronment. 

Distributed File System (Dfe) — a utility for Windows NT 
Server that provides file services in a Microsoft envi- 
ronment. 

Network File System (NFS)— NFS is a native UNIX file 40 
access protocol and is also available as an operating 
system add-on product that provides distributed file 
services. Sun Microsystems introduced NFS in 1985. 
NFS has been widely adopted and has been ported to a 
variety of platforms. 45 

The following are examples of products that provide NFS 
services. 

Sun Microsystems' NFS and WebNFS Novell's Intranet- 
Ware NFS Services 

AFS — A distributed file system for distributed UNIX 50 
networks; derived from Carnegie-Mellon University's 
Andrew File System. Similar to NFS, but differs in terms of 
the name space, system performance, security, etc. AFS is 
distributed by Transarc. 

IBM/Transarc's Distribute File System (DFS) — a scale- 55 
able distributed file system that offers replication, security, 
etc. 

Paging 714 

Wireless short messaging (i.e., paging) can be imple- 
mented through wireless systems such as paging networks, 60 
GSM voice/data networks, PCS voice/data networks, and 
dedicated wireless data networks. Paging virtual resource 
services provide the message formatting and display func- 
tionality that allows network nodes to interface with wireless 
paging systems. This service emulates the capabilities of 65 
one-way and two-way pagers. Paging systems allow pages 
to be generated in various ways: 
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E-mail messages to a specified mailbox 

DTMF (touch tone) signaling to a voice response system 

Encoded digital messages transferred into a paging pro- 
vider gateway 

Messages transferred to a locally attached two-way wire- 
less pager 
Possible Product Options 
TelAlert; e-mail Systems 

e-mail systems — some e-mail systems and fax servers can 
be configured to generate pages to notify users when a 
defined event occurs such as e-mail/fax arriving. 

Telamon's TelAlert — TelAlert provides notification capa- 
bilities for UNIX systems. For example, it can page 
support personnel in the event of system problems. 
Phone 1516 

Phone virtual resource services extend telephony capa- 
bilities to computer platforms. For example, an application 
on a desktop computer can place and receive telephone calls 
for the user. Phone virtual resource services may be used in 
customer care centers, help desks, or any other environment 
in which it is useful for a computer to replace a telephone 
handset. 

Phone services enable clients, servers, and specialized 
telephony nodes (PBXs, ACDs, etc.) to control the tele- 
phony environment through the following telephony con- 
trols: 

Call control 

Controls telephone features 
Controls recorded messages 

Manipulates real time call activities (e.g., make call, 
answer, transfer, hold, conference, mute transfer, 
release, route call, call treatments and digits 
collected) 
Telephone status control 

Controls telephone status functions 
Logs users in and out of the system 
Sets ready, not ready, and make busy statuses for users 
The following are examples of uses of Phone virtual 
resources: 

PC Telephony — PC telephony products allow desktop 
computers to act as conduits for voice telephone calls. 

Internet Telephony — Internet telephony products enable 
voice telephone calls (and faxing, voice mail retrieval, 
etc.) through the Internet. For example, an Internet 
telephony product can accept voice input into a 
workstation, translate it into an IP data stream, and 
route it through the Internet to a destination 
workstation, where the data is translated back into 
audio. 

Desktop Voice Mail — Various products enable users to 
manage voice mail messages using a desktop computer. 
Possible Product Options 

Lucent PassageWay; COM2001s TransCOM; NetSpeaks 
WebPhone; VocalTecs Internet Phone; IDTs Net2Phone; 
Octel Communications Unified Messenger 

The following are examples of vendors that provide PC 
telephony products: 

Lucent PassageWay — suite of products that connect PCs 
to PBXs. 

COM2001's TransCOM— voice, data and call- 
management system (dialing, voice mail, faxing, voice 
recognition, caller ID, etc.) for personal computers. 
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The following are examples of Internet telephony prod- 
ucts: 

NetSpeak's WebPhone 
VocalTec's Internet Phone 
IDT's Net2Phone 

The following is an example of a desktop voice mail 
product: 

Octel Communication's Unified Messenger 
Terminal 1518 

Terminal services allow a client to connect to a non-local 
host via a network and to emulate the profile (e.g., the 
keyboard and screen characteristics) required by the host 
application. For example, when a workstation application 
logs on to a mainframe, the workstation functions as a dumb 
terminal. Terminal Services receive user input and send data 
streams back to the host processor. If connecting from a PC 
to another PC, the workstation might act as a remote control 
terminal (e.g., PCAnywhere). 
The following are examples of Terminal services: 
Telnet — a simple and widely used terminal emulation 
protocol that is part of the TCP/IP communications 
protocol. Telnet operates establishing a TCP connection 
with the remotely located login server, minicomputer or 
mainframe. The client's keyboard strokes are sent to 
the remote machine while the remote machine sends 
back the characters displayed on the local terminal 
screen. 

3270 emulation — emulation of the 3270 protocol that is 

used by IBM mainframe terminals. 
tn3270 — a Telnet program that includes the 3270 protocol 

for logging onto IBM mainframes; part of the TCP/IP 

protocol suite. 

X Window System — allows users to simultaneously 
access applications on one or more UNIX servers and 
display results in multiple windows on a local display. 
Recent enhancements to XWS include integration with 
the Web and optimization of network traffic (caching, 
compression, etc.). 

Remote control — While terminal emulation is typically 
used in host -based environments, remote control is a 
sophisticated type of client/server Terminal service. 
Remote control allows a client computer to control the 
processing on a remote desktop computer. The GUI on 
the client computer looks as if it is the GUI on the 
remote desktop. This makes it appear as if the remote 
applications are running on the client. 

rlogin — a remote terminal service implemented under 
BSD UNIX, The concept behind rlogin is that it sup- 
ports "trusted" hosts. This is accomplished by having a 
set of machines that share common file access rights 
and logins. The user controls access by authorizing 
remote login based on a remote host and remote user 
name. 

Possible Product Options Hummingbird's Exceed; Network 
Computing Devices' PC-Xware; Citrix WinFrame; Carbon 
Copy; pc ANYWHERE; Stac's Reachout; Traveling Soft- 
ware's LapLink 

The following are examples of X Window System prod- 
ucts: 

Hummingbird's Exceed 

Network Computing Devices' PC-Xware 

The following are examples of remote control products: 

Citrix 's WinFrame 

Microcom's Carbon Copy 

Symantec's pc ANYWHERE 
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Stac's Reachout 
Traveling Software's LapLink 
Printing 1520 

Print services connect network workstations to shared 
5 printers. The administration of Print Services is usually 
handled by a print server. Depending on the size of the 
network and the amount of resources the server must 
manage, the print server may run on a dedicated machine or 
on a machine that performs other server functions. A primary 
10 function of print servers is to queue print jobs sent to 
network printers. The queued jobs are stored in a print buffer 
on the print server and are sent to the appropriate network 
printer as it becomes available. Print services can also 
provide the client with information including print job status 
and can manage in-progress print jobs. 
15 Possible Product Options 

Novell's Netware Distributed Print Services (NDPS); 
Novell's Netware UNIX Print Services; Microsoft; Win- 
dows NT Server; Line Printer Daemon (LPD) 
The following are examples of print server products: 
20 Novell's Netware Distributed Print Services (NDPS) — 
provides central management of print services for Net- 
Ware networks. 
Novell's Netware UNIX Print Services — a supplement to 
Novell's NetWare 4,1 server which allows NetWare 
25 and UNIX clients to share UNIX or Netware printers. 
Microsoft Windows NT Server — provides central man- 
agement of print services for NT networks. 
Line Printer Daemon (LPD) — UNIX print management 
facilities, which include client and server utilities for 
30 spooling print jobs. Related programs include lpr 
(sends print job to spool) and lp (sends request to 
printer). 
Audio/Video 1522 

Audio/Video services allow nodes to interact with multi- 
35 media data streams. These services may be implemented as 
audio -only, video-only, or combined audio/video: 
Audio services — Audio services allow components to 
interface with audio streams such as the delivery of 
music or radio content over data networks. 
4Q Video services — Video services allow components to 
interface with video streams such as video surveillance. 
Video services can add simple video monitor capabili- 
ties to a computer, or they can transform the computer 
into a sophisticated video platform with the ability to 
generate and manipulate video. 
Combined Audio/Video services — Video and audio con- 
tent is often delivered simultaneously. This may be 
accomplished by transferring separate audio and video 
streams or by transferring a single interleaved stream. 
Examples include video conferencing and television 
50 (traditional or interactive). 

Audio/Video services can include the following function- 
ality: 

Streams content (audio, video, or both) to end users 
Manages buffering of data stream to ensure uninterrupted 
55 viewing/listening 

Performs compression and decompression of data 
Manages communications protocols to ensure smooth 

delivery of content 
Manages library of stored content and/or manages gen- 
60 eration of live content 

Audio/Video services draw upon lower-level services 
such as streaming and IP Multicast in order to efficiently 
deliver content across the network. 
Possible Product Options 
65 Progressive Networks RealVideo; Microsoft's NetShow; 
Vxtremes Web Theater; Inlels ProShare; Creative Labs 
Video WebPhone 
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The following products are examples of video servers: 
Progressive Networks* RealVideo 
Microsoft's NetShow 
Vxtreme's Web Theater 

The following products are examples of video conferenc- 
ing systems: 
Intel's ProShare 

Creative Labs' Video WebPhone 
Directory Services 1504 

A full-featured Directory Service organizes, categorizes 
and names networked resources in order to provide a com- 
prehensive picture of clients, servers, users, applications and 
other resources. The service typically includes a database of 
objects, representing all nodes and resources on a network. 
The database manages relationships between users and 
networks, network devices, network applications, and infor- 
mation on the network. The Directory service can organize 
network nodes to reflect the topology and organization of the 
enterprise and its policies. The Directory service makes 
resources location and platform independent, since it allows 
users to locate resources via the directory and regardless of 
their physical location. The Directory service also maps 
between logical resource names (e.g., "Marketing_Printe^*) 
and physical resource address (e.g., 10.27.15.56). (See 
Name service, below). 

Directory service products utilize Security services to 
track access rights for access to network resources and 
information. The Directory service is an efficient way to 
manage resource security, since the directory offers a logical 
representation of all resources in the enterprise. In addition, 
the Directory service can act as a single point of entry into 
the network, meaning users can receive access to allowed 
resources by authenticating themselves a single time to the 
Directory service. (For more information on authentication 
and authorization, refer to the Comm. Security service.) 

In summary, the Directory service performs the following 
functions: 

Stores information about network resources and users and 
tracks relationships 

Organizes resource access information in order to aid 
resources in locating and accessing other resources 
throughout the network 

Provides location transparency, since resources are 
accessed through a directory rather than based on their 
physical location 

Converts between logical resource names and physical 
resource addresses 

Interacts with Security services such as authentication and 
authorization track identities and permissions 

Provides single network logon to file and print resources; 
can provide single network logon for network applica- 
tions that are integrated with the Directory service 

Distributes directory information throughout the enter- 
prise (for reliability and location-independent access) 

Synchronizes multiple directory databases 

Enables access to heterogeneous systems (integration of 
various network operating systems, platforms, etc.) 

Directory Standards — There are a variety of standards for 
directories. Vendor-specific directory products build upon 
(and extend) standards to provide a robust, full-featured 
enterprise directory. 

The following are examples of standards related to Direc- 
tory services: 

X.500 an ITU-T standard for a hierarchical directory 
containing user and resource information; includes 
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Directory Access Protocol (DAP), which can be used to 
access directory information. 
Lightweight Directory Access Protocol (LDAP) a de facto 
standard for accessing X.500-compatible directory 
5 information in an Internet/intranet environment. 
Implementation Considerations 

One of the most popular network directory services is 
Novell Directory Services (NDS) used with Netware 4.x. 
This system allows users to access services and resources 
30 with a single login, regardless of where the user location is 
or where the resource location is. Another example of a 
directory service is the ISO X.500 standard. This method is 
not widely used due to its high overheads. In addition to 
these two protocols, Windows NT uses a similar system 
35 called Primary Domain Control. This system allows for the 
same type of directory mapping as NDS and X.500. 

Another protocol that has emerged is the Lightweight 
Directory Access Protocol (LDAP), which is a slimmed- 
down version of the X.500 directory client and is seen as a 
20 possible replacement for X.500. LDAP is a standard proto- 
col for accessing and updating directory information in a 
client/server environment; it has evolved into an emerging 
standard for directory replication for the Internet, and is 
backed by vendors such as Netscape, Novell, Microsoft, 
25 IBM and AT&T that can provide low-level compatibility 
among directory systems. 

Another helpful feature to look out for is support for 
dynamic IP addressing via DHCP. This lets the router handle 
the process of sharing a small number of IP addresses among 
30 the members of the workgroup. Support for dynamic IP 
addressing is now part of Windows 95 and Macintosh 
System 7,6, among other operating systems. 
' Possible Product Options 

Novells Netware Directory Service; Netscapes Directory 
35 Server; Microsofts Active Directory; Banyan Systems 
StreetTalk 

The following are examples of products that provide 
full-featured Directory services. 
Novell's Netware Directory Service 
40 Netscape's Directory Server 

Microsoft's Active Directory Banyan Systems' StreetTalk 
The following is an example of a meta-directory product: 
Zoomit VIA — integrates network operating system 
45 directories, application databases, and human resource 
databases (includes Lotus cc:Mail, Lotus Notes, Novell 
NDS, Microsoft NT Domain Controller and Active 
Directory, Microsoft Exchange, Banyan VINES, 
Netscape Directory Server), thus allowing unified 
50 access and maintenance. 

The following are examples of Name services: 
Domain Name Service — The most common and widely 
used Name Service on the Internet is Domain Name 
Service (DNS) which resolves a pronounceable name 
55 into an IP address and vice versa. For instance, DNS 
could resolve the domain name of www.ac.com to be 
204.167.146.195. DNS functionality is distributed 
across many computers within the network. 
Microsoft's Windows Internet Name Service (WINS) — 
60 WINS is Microsoft's proprietary method for mapping IP 
addresses to NetBIOS device names. WINS works with 
Windows 3.x, Windows 95, and Windows NT clients. 

The following are examples of products that provide 
Domain services: 
65 Network Information Service (NIS) — Developed and 
licensed by Sun Microsystems for use in UNIX 
environments, NIS tracks user names, passwords, user 
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IDs, group IDs, and host names (along with other 
system Qles) through a centralized NTS database, 
Microsoft's Windows NT Server Domain Controller 
Domain Services 1524 

A network domain is a set of network nodes under 
common control (i.e., common security and logins, unified 
addressing, coordinated management, etc.). Domain ser- 
vices manage these types of activities for the network nodes 
in a domain. Domain services may be limited in their ability 
to support heterogeneous systems and in the ability to scale 
to support the enterprise. 
Name Service 1526 

The Name service creates a logical "pronounceable" 
name in place of a binary machine number. These services 
could be used by other communications services such as File 
Transfer, Message Services, and Terminal Services. A Name 
service can be implemented on its own, or as part of a 
full-featured Directory service. 
Core Messaging 1528 

Broadly defined, Messaging services enable information 
or commands to be sent between two or more recipients. 
Recipients may be computers, people, or processes within a 
computer. Messaging Services are based on specific proto- 
cols. A protocol is a set of rules describing, in technical 
terms, how something should be done. Protocols facilitate 
transport of the message stream. For example, there is a 
protocol describing exactly what format should be used for 
sending specific types of mail messages. Most protocols 
typically sit "on top" of the following lower level protocol: 
TCP/IP— Transmission Control Protocol/Internet Proto- 
col (TCP/IP) is the principle method for transmitting 
data over the Internet today. This protocol is respon- 
sible for ensuring that a series of data packets sent over 
a network arrive at the destination and are properly 
sequenced. 

Messaging services transfer formatted information from 
one process to another. By drawing upon Messaging 
services, applications can shield themselves from the com- 
plexity of the low-level Transport services. The Core Mes- 
saging services category includes styles of messaging that 
support basic inter-process communication (IPC). There are 
a variety of architecture options used to support IPC. They 
can be divided into Store and Forward, Synchronous and 
Asynchronous Message Services. 

Store and Forward Message Services — provide deferred 
message service processing. A Store and Forward Mes- 
sage Service may use an E-Mail infrastructure upon 
which to build applications. Common uses would be 
for forms routing and E-mail. 
Synchronous Message Services — allow an application to 
send a message to another application and wait for a 
reply before continuing. Synchronous messaging is 
typically used for update and general business transac- 
tions. It requires time-out processing to allow the 
application to re-acquire control in the event of failure. 
Asynchronous Message Services allow an application to 
send a message to another application and continue 
processing before a reply is received. Asynchronous 
messaging is typically used for larger retrieval type 
processing, such as retrieval of larger lists of data than 
can be contained in one message. 
Additionally, inter-process messaging services are typi- 
cally one of two messaging types: 

Function Based — uses the subroutine model of program- 
ming. The message interface is built upon the calling 
program passing the appropriate parameters and receiv- 
ing the returned information. 
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Message Based — message -based approach uses a defined 
message format to exchange information between pro- 
cesses. While a portion of the message may be 
unstructured, a defined header component is normally 
5 included, A message-based approach is not limited to 
the call/return structure of the function-based model 
and can be used in a conversational manner. 
Core Messaging services are categorized by the charac- 
teristics of the information being transferred: 
10 File Transfer 
RPCs 

Message- Oriented Middleware 
Streaming 

How do Messaging services compare to Transaction Pro- 

15 cessing (TP) services? TP services offer broad functionality 
to support application management, administrative controls, 
and application-to-application message passing. TP services 
may include global transaction coordination, distributed 
two-phase commit, database support, coordinated recovery 
after failures, high availability, security, and work load 

20 balancing. TP services may utilize Messaging services, 
which provide basic interprocess communication. 

Another category of Messaging services, Specialized 
Messaging services, includes services that extend Core 
Messaging services to provide additional functionality. 

25 Implementation Considerations 
Is guaranteed delivery required? 

RPCs do not support guaranteed message delivery tech- 
niques such as store-and-forward and queuing. 
Consequently, RPCs depend upon the availability of the 

30 physical network and server processes. Therefore, network 
stability is important to consider when deciding to use RPCs. 
How important is flexibility? 

In general, RPCs work best with tightly coupled applica- 
tions or in environments where significant application modi- 

35 fications are unlikely. RPCs may be desirable if the appli- 
cation being developed is intended to be shrink wrapped and 
sold. 

Is synchronous or asynchronous program control required? 

Function based middleware such as RPCs traditionally 
provide synchronous program control. Therefore, they tend 

40 to pass control from the client process to the server process. 
When this occurs, the client is dependent on the server and 
must wait to perform any additional processing until the 
servers response is received. This type of program control is 
also known as blocking. Some RPC vendors are enhancing 

45 their products to support asynchronous program control as 
well. 

What type of conversation control is required? 

RPCs permit one side of the conversation (the client) to 
only make requests, while the other side (the server) may 

50 only make replies. Conversation control is passed from the 
client to the server since the client, for each request, causes 
one or more functions to execute on the server while it waits 
for its reply. With RPCs, developers do not need to be 
concerned with the state of the conversation between the 

55 client and the server. In most cases, the absence of conver- 
sation states simplifies the design and development effort. 
Is yclient interested in a stable or emerging technology? 

RPCs have existed for many years and are considered to 
be a mature, stable, proven solution. 

60 Is it important to minimize development complexity? 

Due to the synchronous program control and the request/ 
reply conversation control, RPCs can be fairly straightfor- 
ward to design and build. The complexity is also reduced 
since RPC calls are completely independent of any previous 

65 or future RPC call. On the other band, RPCs usually require 
a specific RPC compiler, which may add to the development 
complexity. 
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Are extended technical capabilities required? 

If any of the following capabilities are required, message 
based middleware should be considered. It may also be 
possible to incorporate these capabilities into a function 
based middleware solution, but significant custom modifi- 5 
cation and development may be required. 

Guaranteed Delivery 

Store and Forward 

Queuing ^ 

Priority Message Delivery 

Dynamic Routing 

Multicasting and Broadcasting 

Load Balancing 
Product Considerations 15 
What are the client's budgetary constraints? 

Costs may vary greatly among middleware products. 
There are many factors to consider when looking at middle- 
ware. To begin, middleware products can require extensive 
consulting and support services just to install. Therefore, 20 
understanding the set-up and configuration costs are impor- 
tant. There are also additional products required to complete 
an environment such as additional networking software 
which may be necessary for each individual client. In 
addition, development seat costs and production seat costs 25 
must considered. 

Is synchronous or asynchronous communications required? 

All RPC products support synchronous program control. 
Some vendors are enhancing their products to provide 
asynchronous capabilities as well. Asynchronous means that 30 
while information is being passed via send and receive 
commands, programs can continue to process other tasks 
while waiting for a response to a request. 
What's the clients position on DCE? 

DCE software, developed by Open Systems Foundation 35 
(OSF), is licensed to OSF-member companies to form 
products that provide common services. The RPC is one of 
several DCE common services. Some clients may desire to 
be aligned with DCE-based solutions. 

Is the middleware compatible with the other technology 40 
architecture components? 

Communications middleware products must integrate 
with other technology architecture components, develop- 
ment tools, and operations tools. Therefore, it is necessary to 
understand the compatibility between these tools and the 45 
communications middleware product. 
Is it important for the product to support multiple platforms 
and operating systems? 

The middleware products must support the required com- 
puting platform such as Windows, UNIX, and Mainframe. It 50 
is common for vendors to claim that their product supports 
various platforms and operating systems, when in reality, 
that platform and operating system may be supported in a 
future release. It is important to request references of imple- 
mentations of the platforms and operating systems that are 55 
important to your specific environment. 
What is the client's vendor direction? 

When evaluating a middleware product, its important to 
consider the clients relationships with vendors in the tech- 
nology market. For example, if the client has a strong 60 
relationship with a vendor who is also in the middleware 
market, it would be wise to investigate and consider such a 
vendor for the clients middleware solution. 
Is it important for the product to support multiple network 
protocols? 65 

The middleware products must support the network pro- 
tocols such as TCP/IP, LU6.2, and IPX/SPX that are impor- 
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tant to your specific environment. It is important to note that 
protocols can vary across platforms. Ensure that the clients 
specific transport protocol version is supported by the com- 
munications middleware product. For example, communi- 
cations middleware vendors may support TCP/IP but they 
may not support the particular TCP/IP vendor that the client 
has selected. 

Is a quick response time critical? 

RPC performance may vary between products based upon 
the internal mechanisms and techniques of the product. For 
example, slow performance may be due to the processing 
overhead associated with each RPC call. Some RPC prod- 
ucts may improve performance by utilizing special tech- 
niques used to invoke the server every time a client request 
arrives. Performance should be considered as a product 
differentiator. 

What level of security is required? 

There are potential security issues associated with the 
execution of commands on a remote system. Some vendors 
install security features into their products. It is also possible 
for the architecture team to build additional security into the 
overall solution. 

Is yclient interested in a stable or emerging product? 

Vendors should be evaluated on the quality of service they 
offer, their market share, the age of their product, the 
installed base of their product, and their financial stability. In 
addition, since this market is still emerging, there are many 
small vendors in the market trying to offer solutions. Vendor 
and product stability should be taken very seriously. 
File Transfer 1530 

File Transfer services enable the sending and receiving of 
files or other large blocks of data between two resources. In 
addition to basic file transport, features for security, guar- 
anteed delivery, sending and tracking sets of files, and error 
logging may be needed if a more robust file transfer archi- 
tecture is required. The following are examples of File 
Transfer standards; 

File Transfer Protocol (FTP) allows users to upload and 
download files across the network. FTP also provides a 
mechanism to obtain filename, directory name, 
attributes and file size information. Remote file access 
protocols, such as Network File System (NFS) also use 
a block transfer method, but are optimized for online 
read/write paging of a file. 
HyperText Transfer Protocol (HTTP)— Within a Web- 
based environment, Web servers transfer HTML pages 
to clients using HTTP. HTTP can be thought of as a 
lightweight file transfer protocol optimized for trans- 
ferring small files. HTTP reduces the inefficiencies of 
the FTP protocol. HTTP runs on top of TCP/IP and was 
developed specifically for the transmission of hypertext 
between client and server. The HTTP standard is 
changing rapidly. 
Secure Hypertext Transfer Protocol (S-HTTP) — a secure 
form of HTTP, mostly for financial transactions on the 
Web. S-HTTP has gained a small level of acceptance 
among merchants selling products on the Internet as a 
way to conduct financial transactions (using credit card 
numbers, passing sensitive information) without the 
risk of unauthorized people intercepting this informa- 
tion. S-HTTP incorporates various cryptographic mes- 
sage formats such as DSA and RSA standards into both 
the Web client and the Web server. 
File Transfer and Access Management (FTAM) — The 
OSI (Open Systems Interconnection) standard for file 
transfer, file access, and file management across plat- 
forms. 
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Implementation Considerations 

Additional options for File Transfer Services in a homo- 
geneous environment could include the native operating 
systems copy utility, i.e. Windows NT Copy features. 
Possible Product Options 5 
Computer Associates CA-XCOM; Remote Ware; Hewlett- 
Packards HP FTAM; IB Ms Files On-Demand gateway 
The following are examples of File Transfer products: 
Computer Associates CA-XCOM; RemoteWare; Hewlett- 

Packards HP FTAM; IBMs Files On-Demand gateway 10 
The following are examples of File Transfer products: 
Computer Associates* CA-XCOM — provides data trans- 
port between mainframes, midrange, UNIX, and PC 
systems. XcelleNet's RemoteWare — retrieves, 
appends, copies, sends, deletes, and renames files 15 
between remote users and enterprise systems. Hewlett- 
Packard's HP FTAM — provides file transfer, access, 
and management of files in OSI networks. 
The following product provides File Transfer translation: 
IBM's Files On-Demand gateway — acts as a gateway 20 
between Web-based and mainframe-based FTP ser- 
vices to allow users to download mainframe-based files 
from a World Wide Web browser. 
RPC 1532 

RPCs (Remote Procedure Calls) are a type of protocol by 25 
which an application sends a request to a remote system to 
execute a designated procedure using the supplied argu- 
ments and return the result. RPCs emulate the function call 
mechanisms found in procedural languages (e.g., the C 
language). This means that control is passed from the main 
logic of a program to the called fuinction, with control 
returning to the main program once the called function 
completes its task. Because RPCs perform this mechanism 
across the network, they pass some element of control from 
one process to another, for example, from the client to the 
server. Since the client is dependent on the response from the 
server, it is normally blocked from performing any addi- 
tional processing until a response is received. This type of 
synchronous data exchange is also referred to as blocking 
communications. 
Possible Product Options 

Sun Microsystems ONC+; OpenGroups DCE RPC; Nov- 
ells NetWare RPC; NobleNet's EZ-RPC; Transarcs DCE 
RPC; Microsofts Windows95/NT RPC 

Sun Microsystems' ONC (Open Network Computing) 

OpenGroup's DCE (Distributed Computing 
Environment) 

Novell's NetWare RPC NobleNet EZ-RPC Transarc's 
DCE 

Microsoft's Windows95/NT RPC 
Message Oriented 1534 

Message-Oriented Middleware (MOM) refers to the pro- 
cess of distributing data and control throughout the 
exchange of records known as messages. MOM provides the 55 
application developer with a set of simple verbs (e.g., 
connect, send, receive, and disconnect) that are used to 
exchange information with other distributed applications. 

Message-Oriented Middleware is responsible for manag- 
ing the interface to the underlying communications archi- 6Q 
lecture via the communications protocol APIs and ensuring 
the delivery of the information to the remote process. This 
interface provide the following capabilities: 

Translating mnemonic or logical process names to oper- 
ating system compatible format 65 

Opening a communications session and negotiating 
parameters for the session 
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Translating data to the proper format 

Transferring data and control messages during the session 

Recovering any information if errors occur during trans- 
mission 

Passing results information and status to the application. 
An application continues processing after executing a 
MOM request, allowing the reply to arrive at a subsequent 
time. Thus, unlike RPCs, MOM implements a "non- 
blocking" or asynchronous messaging architecture. 

Message-Oriented Middleware products typically support 
communication among various computing platforms (e.g., 
DOS, Windows, OS/2, Macintosh, UNIX, and mainframes). 

There are three types of Message-Oriented Middleware 
commonly implemented: 
Message Passing 
Message Queuing 
Publish and Subscribe 

Message Passing — as illustrated in FIG. 17, is a direct, 
application-to-application communication model. 
An application request is sent in the form of message 
from one application to another. The communication 
method can be either synchronous like RPCs or 
asynchronous (through callback routines). In a 
message -passing model, a direct link between two 
applications that participate in the message exchange 
is always maintained. 
Message Queuing (also known as Store and 
Forward) — as depicted in FIG. 18, is an indirect 
application to application communication model that 
allows applications to communicate via message 
queues, rather than by calling each other directly. 
Message queuing is asynchronous by nature and 
connectionless, meaning that the recipient need not 
be directly available when the message is sent. 
Moreover, it implies support for reliable, guaranteed 
and assured (non -duplicate) message delivery. 
Publish and Subscribe (also known as Push 
messaging) — as shown in FIG. 19, is a special type 
of data delivery mechanism that allows processes to 
register an interest in (i.e., subscribe to) certain 
messages or events. An application then sends 
(publishes) a message, which is then forwarded to all 
processes that subscribe to it. 
Implementation Considerations 

When trying to decide whether to use MOM technology, 
keep the following characteristics of this type of middleware 
in mind: 

MOMs are high speed, generally connectionless and are 
usually deployed for executing applications with a 
nonblocking sender 

MOM solutions are especially useful for inter-application 
communication and are increasingly popular for inter- 
enterprise work 

MOMs support end-to-end business applications and pro- 
cess inter-operability 

MOMs are designed for heavily used production appli- 
cations and are generally capable of high throughput 
rates and fast transfer times. Data is usually forwarded 
immediately, although it is possible to store it for later 
processing 
Possible Product Options 

PeerLogics PIPES; IBM MQSeries; BEAs MessageQ; 
Momentum XIPC; Microsoft MQ (Falcon); TibCo's Ren- 
dezvous 
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Message Passing 
PeerLogic's PIPES 

PIPES Platform applications communicate through a 
messaging interface that allows asynchronous, non- 
blocking communications. The messaging model is 
well-suited to complex multi-tier applications 
because it inherently supports asynchronous, event- 
driven communications. 
Message Queuing 
IBM's MQSeries 

New features found in version 5 include: 
A new Internet gateway that allows customers and 
partners to run mission critical business applica- 
tions over an unreliable network. 
Enhanced message distribution carries more busi- 
ness information, while minimizing use of net- 
works. 

Performance improvements gives message transmis- 
sion at least 8 times faster than previous versions 

Resource Coordination ensures that data held in 
databases is always updated completely — or not at 
all, if processing cannot complete. 

Additional developer features include further lan- 
guage support for C++, Java and PL/1, and 
interoperability with current and previous 
MQSeries versions. 

Easier implementation because MQSeries now has 
the same install and use characteristics as other 
IBM Software Servers. 
BEA's MessageQ 

Key highlights of the MessageQ product include: 

High performance — up to thousands of non- 
recoverable messages/second; hundreds of recov- 
erable messages/second 

Both synchronous, and asynchronous message deliv- 
ery 

Broadest platform support in the industry including 
UNIX, Windows NT, Open VMS, and mainframes 

Common Application Programming Interface (API) 

Publish and subscribe (broadcasting) 

Microsoft Windows client product with support for 
DLLs (Dynamically Linked libraries), Visual 
Basic, and Power Builder development environ- 
ments 

Message recovery on all BEA MessageQ clients and 
servers 

Interoperability with IBM MVS/CICS and IBM 
MVS/IMS 

Large message size-up to 4 MB-eliminates need for 
message partitioning 
Momentum's XIPC 
XIPC is an advanced software toolset for the develop- 
ment of multitasking and distributed applications. 
XIPC provides fault-tolerant management of guar- 
anteed delivery and real-lime message queuing, syn- 
chronization semaphores and shared memory, all of 
which are network-transparent. 
Microsoft Message Queue Server (MSMQ, formerly 
known as Falcon) 
Publish and Subscribe 
TibCo's Rendezvous 

TIB/Rendezvous* publish/subscribe technology is the 
foundation of TIBnet, TibCos solution for providing 
information delivery over intranets, extranets and the 
Internet. It is built upon The Information Bus® 
(TIB®) software, a highly scaleable messaging 



30 



35 



20 



25 



30 



35 



40 



45 



50 



55 



middleware technology based on an event-driven 
publish/subscribe model for information distribu- 
tion. Developed and patented by TIBCO, the event- 
driven, publish/subscribe strategy allows content to 
be distributed on an event basis as it becomes 
available. Subscribers receive content according to 
topics of interest that are specified once by the 
subscriber, instead of repeated requests for updates. 
Using IP Multicast, TIBnet does not clog networks, 
but instead, provides for the most efficient real-time 
information delivery possible. 
Streaming 1536 

Streaming is the process of transferring time-sensitive 
data streams (e.g., video and/or audio) in real-time. Stream- 
ing differs from the other types of Core Messaging services 
in that it delivers a continuous, one-way stream of data, 
rather than the relatively short messages associated with 
RPC and Message-Oriented Middleware messaging or the 
large, batch transfers associated with File Transfer. (While 
the media stream is one-way from the server to the client, the 
client can issue stream controls to the server.) Streaming 
may be used to deliver video, audio, and/or other real-time 
content across the Internet or within enterprise networks. 

Streaming is an emerging technology. While some mul- 
timedia products use proprietary streaming mechanisms, 
other products incorporate standards. The following are 
examples of emerging standards for streaming protocols. 
Data streams are delivered using several protocols that are 
layered to assemble the necessary functionality. 

Real-time Streaming Protocol (RTSP)— RTSP is a draft 
Internet protocol for establishing and controlling 
on-demand delivery of real-time data. For example, 
clients can use RTSP to request specific media from a 
media server, to issue commands such as play, record 
and pause, and to control media delivery speed. Since 
RTSP simply controls media delivery, it is layered on 
top of other protocols, such as the following. 

Real-Time Transport Protocol (RTP) — Actual delivery of 
streaming data occurs through real-time protocols such 
as RTP, RTP provides end-to-end data delivery for 
applications transmitting real-time data over multicast 
or unicast network services. RTP conveys encoding, 
timing, and sequencing information to allow receivers 
to properly reconstruct the media stream. RTP is inde- 
pendent of the underlying transport service, but it is 
typically used with UDP. It may also be used with 
Multicast UDP, TCP/IP, or IP Multicast. 

Real-Time Control Protocol (RTCP)— RTP is augmented 
by the Real-Time Control Protocol. RTCP allows nodes 
to identify stream participants and communicate about 
the quality of data delivery. 

The following table summarizes the protocol layering that 
supports Streaming: 



functionality 



sample protocol 
options 



architecture service 
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controlling media 
delivery 
monitoring data 
stream 
end-to-end 
delivery of stream 
message transport UDP, Multicast UDP, 
TCP 



RTSP or proprietary 
RTCP or proprietary 
RTP or proprietary 



Streaming Messaging service 
Streaming Messaging service 
Streaming Messaging service 
Message Transport service 
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FIG. 20 depicts Streaming, in which a real-time data 
stream is transferred. 
Possible Product OptionsOptions 

Netscape's Media Server; Progressive Networks Real 
Audio/Video; VXtremes WebThealer 

The following are examples of products that implement 
Streaming Messaging (based upon RTSP or other standards 
or proprietary approaches): 

Netscape's Media Server 

Progressive Networks' Real Video VXtreme's WebThe- 
ater 

Specialized Messaging 1538 

Specialized Messaging services extend the Core Messag- 
ing services to provide additional functionality, including: 
Provides messaging among specialized systems by draw- 
ing upon basic messaging capabilities 
Defines specialized message layouts 
Defines specialized inter-system protocols 
Suggests ways in which messaging draws upon directory 
and security services in order to deliver a complete 
messaging environment 
An example of a specialized messaging service is Mail 
Messaging. Mail Messaging is a specialized implementation 
of store-and-forwarding MOM (message-oriented 
middleware) messaging, in that Mail Messaging defines 
specialized, mail-related message layouts and protocols that 
utilize store -and-forward messaging. 
E-Mail 1540 

E-Mail takes on a greater significance in the modern 
organization. The E-Mail system, providing it has sufficient 
integrity and stability, can function as a key channel through 
which work objects move within, and between organizations 
in the form of messages and electronic forms. An E-Mail 
server stores and forwards E-Mail messages. Although some 
products like Lotus Notes use proprietary protocols, the 
following protocols used by E-Mail Services are based on 
open standards: 

X.400 — The X.400 message handling system standard 
defines a platform independent standard for store-and- 
forward message transfers among mail servers. X.400 
is often used as a backbone e-mail service, with gate- 
ways providing interconnection with end-user systems. 
SMTP— Simple Mail Transfer Protocol (SMTP) is a 
UNIX/Internet standard for transferring e-mail among 
servers. 

MIME — Multi-Purpose Internet Mail Extensions 
(MIME) is a protocol that enables Internet users to 
exchange multimedia e-mail messages. 

POP3 — Post Office Protocol (POP) is used to distribute 
e-mail from an SMTP server to the actual recipient. 

IMAP4 — Internet Message Access Protocol, Version 4 
(IMAP4) allows a client to access and manipulate 
electronic mail messages on a server. IMAP4 permits 
manipulation of remote message folders, called 
"mailboxes", in a way that is functionally equivalent to 
local mailboxes. IMAP4 also provides the capability 
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for an off-line client to re-synchronize with the server. 
IMAP4 includes standards for message handling fea- 
tures that allow users to download message header 
information and then decide which e-mail message 
5 contents to download. 
Implementation Considerations 

A number of E-mail servers from vendors including HP 
and Netscape are built around SMTP, and most proprietary 
protocol E-Mail servers now provide SMTP gateways. 
3Q The Multi-part Internet Mail Extensions (MIME) stan- 
dard has gained acceptance as the Internet mechanism for 
sending E-mail containing various multimedia parts, such as 
images, audio files, and movies. S/MIME, or secure MIME 
adds encryption and enables a secure mechanism for trans- 
^ 5 ferring files. 

Although currently POP3 is the popular Internet E-Mail 
message handling protocol, recently the lesser known 
IMAP4 protocol has been gaining in adoption among mail 
server and mail client software providers. IMAP was 
2Q designed to add features beyond POP that allow users to 
store and archive messages and support mobile users that 
need to keep messages on a central server as well as on their 
laptop. 

Organizations are looking to use vehicles like E-Mail and 
the Internet to enable communications with customers and 
trading partners. The least common denominator E-mail 
capability today is very rudimentary (ASCII text). But as the 
standards listed here as well as others become integrated into 
most of the popular E-mail products and gateways this will 
3Q change enabling a more flexible and useful commercial 
communications medium. 
Possible Product OptionsOptions 

Microsoft Exchange Server; Lotus cc:mail; Lotus Notes; 
Qualcomm Eudora; TenFours TFS Universal E-Mail Gate- 
35 way; UUcoding; Netscape Mail Server; Post.OfEce; NTMail 
The following E-Mail products are based on the open 
Internet standards defined above: 

Netscape Mail Server — Netscapes implementation of an 
open standards-based client/server messaging system 
40 that lets users exchange information within a company 
as well as across the Internet. It includes support for all 
standard protocols, and is packaged with Netscapes 
SuiteSpot server line. 
Post. Office — one of the leading POP3/SMTP mail servers 
45 for the Internet community as well as corporate intra- 
nets. This message transport agent is based entirely on 
the open standards of the Internet, ensuring maximum 
compatibility with other systems. 
NTMail— an open SMTP and POP 3 mail server for 
50 Windows NT. 

The following are major proprietary E-mail servers used 
in large organizations today: 

Lotus Notes — platform-independent client/server mail 
system. Notes Mail can support over 1,500 active users 
55 per server, offering Internet integration, distributed 
replication and synchronization. Lotus Notes also pro- 
vides integrated document libraries, workflow, calen- 
daring and scheduling, and a cc:Mail user interface. 
Microsofts Exchange Server — Exchange 4.0 provides a 
60 messaging and group ware platform to support collabo- 
ration solutions on Windows machines. Microsoft 
Exchange 5.0 has-support for all of the key Internet 
protocols. These include POP3 for mailbox access, 
SMTP for mail sending and receiving, NNTP for news- 
65 groups and discussion forums, LDAP for directory 
access, HTTP and HTML for access via a web brow — 
and SSL for security. 



05/06/2004, EAST version: 1.4.1 



US 6,5' 

75 

The following products are examples of e-mail systems: 
Microsoft Mail 
Lotus cc:mail 
Qualcomm Eudora 

The following products provides e-mail system transla- 
tion: 

TenFour's TFS Universal E-Mail Gateway — links users 
of Lotus Development Corpus cc:Mail and Notes, 
Novell Inc.'s GroupWise, Microsoft Corp.'s Mail, MCI 
Mail, and SMTP e-mail to Microsoft Exchange. 
UUcoding — process for converting 8-bit binary files into 
7-bit ASCII files for transmission via e-mail over the 
Internet (the Internet only supports seven bit characters 
in e-mail messages); UUencode and UUdecode utilities 
on end nodes perform the conversion. 
Database Access 1542 

Database Messaging services (also known as Database 
Access Middleware) provide connectivity for clients to 
access databases throughout the enterprise. Database mes- 
saging software draws upon basic inter-process messaging 
capabilities (e.g., RPCs) in order to support database con- 
nectivity. Database Messaging services typically provide 
single application seemless access to multiple data sources, 
both relational and non-relational. Additionally, database 
messaging services can be used to facilitate migration of 
data from one environment to another (i.e., MVS/ 
DB2— Sybase) 

There are three types of database access middleware: 

ODBC-like 

Propietary 

Gateway 

Is there a projected growth in data requirements? 

Storage of data in a database allows for more optimal 
future growth since databases scale better than mechanisms 
such as flat files. 

Should the data be secured and controlled? 

Use databases to protect data integrity from multiple user 
access, and hardware and software failures. 
Is it desirable to limit the amount of viewed data? 

Use databases to store large amounts of information and 
to access an individual record(s) without having to inspect 
all the records of a given topic. 
Is there a need to impose data standards? 

Use a database when you wish to store and impose 
standards on data elements. This is important when devel- 
oping enterprise wide solutions, since it is desirable to have 
the different applications access the same structured infor- 
mation. 

Is there a current or potential requirement for a distributed 
architecture? 

Databases allow for the potential of such architectural 
features as a data replication strategy and/or distributed data 
access. 

Is there a need to minimize data duplication? 

Because of their normalized design, relational databases 
are used to reduce data redundancy. This reduces mainte- 
nance and storage requirements. 
Product Considerations 

What are the available administration or systems manage- 
ment features? 

Administration and systems management features such as 
remote management, remote configuration, backup and 
recovery, and disaster recovery should be considered. 
What are the key business requirements? 

Product selection may be influenced by business require- 
ments such as replication and distributed data, parallel 
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processing, complex object support for such purposes as 
multimedia, OLTP, decision support, VLDB, data 
warehousing, and availability (24/7 vs. 8/5). 
What is the availability of market resources to support the 
5 product? 

Personnel available for support (permanent hires, 
contractors), and third party support for skilled resources/ 
training should be considered. 

Are the current data requirements expected to increase? 

Products differ in their ability to scale with respect to 
hardware architecture, transaction throughput, and user 
base. 

How do the vendors compare against one another? 

Issues to consider are type, quality and responsiveness of 
support, alliances/partnerships with other companies, mar- 
35 ket presence (install base, customer list, number of produc- 
tion copies, etc.), vendor industry, alignment of mission and 
vision with that of potential customer/e valuator, product 
philosophy, long-term product plans/strategy, and vendor's 
training. 

20 How well does a product integrate with the current or 
proposed architecture? 

Issues to consider include supported operating systems, 
networks, and other database platforms, availability of data- 
base utilities, application interfaces, development tools, and 
25 third party products, and integration with legacy systems. 
Possible Product Options 

Oracles SQL*Net; Sybases EnterpriseConnectivity; 
Microsoft's Open Database Connectivity (ODBC); Sun Java 
Database Connectivity (JDBC) 
3Q Oracle's SQL* Net — supports database interoperability 
across a variety of transport protocols (e.g., TCP/IP, 
SPX/IPX, SNA, etc.); includes verbs such as connect, 
send, receive, and disconnect; performs transparent 
protocol bridging by allowing multiple protocols to 
reside simultaneously on each node. 
35 Sybase's EnterpriseConnectivity — supports database 
interoperability across a variety of platforms. 
Microsoft's Open Database Connectivity (ODBC) — a 
database programming interface that provides a com- 
mon language for Windows applications to access 
40 databases on a network. 

Sun's Java Database Connectivity (JDBC) — a Java-based 
programming interface that provide a common method 
for Java applications to access databases on a network 
Object Messaging 1544 
45 Object Messaging enables objects to transparently make 
requests of and receive responses from other objects located 
locally or remotely. Objects communicate through an Object 
Request Broker (ORB). An ORB enables client objects to 
access server objects either locally or remotely over a 
50 network and invoke operations (i.e. functions and methods) 
on them. ORBs typically provide interoperability between 
heterogeneous client and server environments: across lan- 
guages and/or operating systems and/or network protocols. 
In that respect some have said that ORBs will become a kind 
55 of "ultimate middleware" for truly distributed processing. A 
standardized Interface Definition Language (IDL) defines 
the interfaces that applications must use to access the ORB 
Services. The two major Object Request Broker standards/ 
implementations are: 
60 Object Management Group's Common Object Request 
Broker Architecture (CORBA) 
Microsoft's (Distributed) Component Object Model 
(COM/DCOM) 

65 CORBA 

Common Object Request Broker Architecture (CORBA) 
is a standard for distributed objects being developed by the 
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Object Management Group (OMG). The OMG is a consor- 
tium of software vendors and end users. Many OMG mem- 
ber companies are developing commercial products that 
support the CORBA standards and/or are developing soft- 
ware that use these standards. CORBA provides the mecha- 
nism by which objects transparently make requests and 
receive responses, as defined by OMG's Object Request 
Broker (ORB). The CORBA ORB is an application frame- 
work that provides interoperability between objects, built in 
different languages, running on different machines in het- 
erogeneous distributed environments. 
Inter-ORB Messaging 

The OMGs Internet Inter-Orb Protocol (HOP) specifies a 
set of message formats and common data representations for 
communication between ORBs over TCP/IP networks. 
CORBA-based Object Messaging is summarized in FIG. 21. 

COM/DCOM 

Component Object Model (COM) is a client/server 
object -based model, developed by Microsoft, designed to 
allow software components and applications to interact with 
each other in a uniform and standard way. The COM 
standard is partly a specification and partly an implementa- 
tion. The specification defines mechanisms for creation of 
objects and communication between objects. This part of the 
specification is paper-based arid is not dependent on any 
particular language or operating system. Any language can 
be used as long as the standard is incorporated. The imple- 
mentation part is the COM library which provides a number 
of services that support a mechanism which allows appli- 
cations to connect to each other as software objects. COM 
is not a software layer through which all communications 
between objects occur. Instead, COM serves as a broker and 
name space keeper to connect a client and an object, but 
once that connection is established, the client and object 
communicate directly without having the overhead of pass- 
ing through a central piece of API code. Originally con- 
ceived of as a compound document architecture, COM has 
been evolved to a full object request broker including 
recently added features for distributed object computing. 
DCOM (Distributed COM) contains features for extending 
the object model across the network using the DCE Remote 
Procedure Call (RPC) mechanism. In sum, COM defines 
how components should be built and how they should 
interact. DCOM defines how they should be distributed. 
Currently COM/DCOM is only supported on Windows- 
based machines. However, third-party vendors are in 
progress of porting this object model to other platforms such 
as Macintosh, UNIX, etc. FIG. 22 illustrates COM Messag- 
ing. 

Implementation Considerations 

Although ORBs provide a mechanism for transparently 
communicating among components located locally or 
remotely, performance issues need to be thoroughly 
addressed before moving components around the network 
Making requests and receiving responses among compo- 
nents located on different machines will take longer that 
having the same communication between components 
located on the same machine. Performance is dependent on 
what type of network is available (LAN, type of LAN, 
WAN, type of WAN, dial-up, wireless, etc.), size of mes- 
sages and number of messages that go across the network. 
Possible Product Options 

Expersoft's CORBAplus; IBM's Component Broker; 
BEASystems ObjectBroker; Iona Technology's Orbix; 
I np rise's Visibroker; Microsofts COM; Software AGs COM 
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CORBA-based ORB Products 
Expersoft's CORBAplus 
IBM's Component Broker 
BEA's Object Broker 
5 Iona Technologies's Orbix 

Inprise's VisiBroker(fonnerly Visigenic) 
COM Products 
Microsoft's DCOM (Windows NT Server, Windows NT 
Workstation, Windows 95, Apple Macintosh, Windows 
10 Java Virtual Machine) 

Software AG's COM (current or planned availability on 
Sun, Digital UNIX, IBM, and HP platforms) 
CTI Messaging 1546 

Computer-Telephone Integration (CTI) integrates com- 
15 puter systems and telephone systems to coordinate data and 
telephony activities. For example, CTI can be used to 
associate a customers database entry with the customers 
telephone call and route the call accordingly. 

Referring to FIG. 23, CTI Messaging supports commu- 
20 nication among clients 2300, CTI servers 2302, PBXs/ 
ACDs 2304, hybrid platforms, networks 2306, and external 
telephony devices. CTI Messaging relies upon proprietary 
PBX/ACD APIs, CTI vendor-specific APIs or message sets, 
and industry-standard APIs. 
25 CTI Messaging has two primary functions: 
Device-specific communication 

Manages direct communications between telephony 

devices and data devices 
Allows applications to control PBXs, key telephone 
systems, ISDN, analog PSTN, cellular, Centrex, etc. 
and supports features such as address translation, call 
setup, call answering, call dropping, and caller ID. 
Provides interface to carrier networks for call delivery 
35 and call-related messaging 

Message mapping 

Translates device -specific communication to generic 
API and/or message set 
CTI products can be divided into the following categories: 
40 CTI Platform-Specific Products — products that can only 
be implemented on the hardware of a specific vendor. 
CTI Telephony-based API Products — include propri- 
etary PBX/ACD-based messaging sets, which permit 
external devices to interface with the vendor's PBX/ 
4S ACD call and station control logic 

CTI Server/Workstation-based or Host-based API 
Products — operate on a particular computer vendor's 
hardware platform and provide call control and mes- 
saging functionality. 
50 CTI Cross-Platform Vendors — products that have been 
ported to multiple hardware platforms/operating sys- 
tems. 

CTI Enabling Solutions — focus solely on call control 
and call/application synchronization functions. 
55 CTI Enterprise Solutions — provide all CTI business 
functions to varying degrees. 
Possible Product Options 

Novell's Netware Telephony Services; Microsoft TAPI; 
Novell TSAPI 

60 Industry-Standard Application Programming Interfaces 
(APIs): 

Microsoft's TAPI 
Novell's TSAPI 

Novell's Netware Telephony Services — Based on Nov- 
65 ell's Telephony Services API (TSAPI), Netware 

Telephony Services is a CTI gateway that integrates 
Novell networks with telephony networks. 
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Other vendors of CTI products include: 

Aspect Telecommunications Corp. 

Genesys Labs 

IBM 

Lucent 

Nortel 

Rockwell 
EDI Messaging 1548 

EDI (Electronic Data Interchange) supports system-to- 
system messaging among business partners by defining 
standard message layouts. Companies typically use EDI to 
streamline commercial transactions within their supply 
chains. 

EDI standards (e.g., EDIFACT, ANSI X12) define record 
layouts for transactions such as "purchase orders". EDI 
services include the generation and translation of EDI mes- 
sages according to the various public message layout stan- 
dards. 

EDI messaging can be implemented via electronic mail or 
customized message -oriented architectures. 
Implementation Considerations 

EDI messages have traditionally been sent between com- 
panies using a VAN (Value Added Network). VANs have 
been criticized for their relatively high cost in comparison to 
public networks like the Internet. Recently, EDI messaging 
vendors such as Premenos have been creating software with 
built-in encryption features to enable companies to send EDI 
transmissions securely over the Internet. 

Web server vendors including Microsoft, Netscape and 
OpenMarket are putting plans in place to add EDI transmis- 
sion capabilities into their Web server products. OpenMarket 
Inc. is working with Sterling and Premenos to integrate their 
EDI management software with OpenMarkets OMTransact 
electronic commerce server software. Netscape is working 
with GEIS in creating Actra Business Systems to integrate 
EDI services with Netscape server products. 
Possible Product Options 

Digital Equipment Corp.s DEC/EDI; Sterling Commerces 
GENTRAN; IBM Global Services Advantis; GE Informa- 
tion Services; Sterling Commerce 
EDI Applications 

Digital Equipment Corp.'s DEC/EDI 

Sterling Commerce's GENTRAN 

EDI value-added networks (VANs)— VANs link EDI 
trading partners and transmit EDI messages through a 
central electronic clearinghouse 

IBM Global Services' Advantis 

GE Information Services 

Sterling Commerce 
Legacy Integration 1550 

Legacy services provide gatewarys to mainframe legacy 
systems. The following protocol is typically used: 

Systems Network Architecture (SNA) is a networking 
connection-oriented protocol architecture which was 
developed in the 1970s by IBM. Currently, SNA and 
TCP/IP are two of the most widely used networking 
protocol architectures. 

Design techniques for integration with existing systems 
can be grouped into two broad categories: 

Front end access — discussed as part of Terminal Emula- 
tion 

Back end access — tend to be used when existing data 
stores have information that is needed in the client/ 
server environment but accessing the information 
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through existing screens or functions is not feasible. 
Legacy Integration messaging services typically 
include remote data access through gateways. A data- 
base gateway provides an interface between the client/ 
5 server environment and the legacy system. The gate- 
way provides an ability to access and manipulate the 
data in the legacy system. 
Implementation Considerations 

Legacy systems hold critical data which must be acces- 
sible by new Netcentric computing solutions. These legacy 
data sources often must be accessed in their current form so 
as to not disrupt the legacy systems. 
Communications Security 1508 

Communications Security services control access to 
network-attached resources. Combining network Security 
15 services with security services in other parts of the system 
architecture (e.g., application and database layers) results in 
robust security. 
Possible Product Options 
UkWeb's Stronghold; UkWeb's SafePassage 
20 UkWeb's Stronghold 

Stronghold was the first web server to support SSL Client 
Authentication. Regular expression-based matching of cli- 
ent certificate information to determine access control is 
possible. Stronghold also has an API for certificate to 
25 useraame mapping so that client certificates may be mapped 
to standard usernames, CA certificates from both Thawte 
and Verisign can be utilized. Uncompromised, full 128-bit 
symmetric encryption is provided in all versions. This 
provides Netcentric systems used outside of the USA or 
30 Canada with secure encryption capabilities. 
UkWebs's SafePassage 

SafePassage is a full-strength, encrypting Web proxy. It is 
designed to supplement the security of browsers whose 
authentication and encryption capabilities have been weak- 
35 ened to comply with United States export regulations. For 
these types of browsers, SafePassage will provide client 
authentication certificates and full-strength encryption (128 
bit). 

Encryption 1552 
40 Encryption services encrypt data prior to network transfer 
to prevent unauthorized interception. (Note that encryption 
can occur within the Communications Services layer, the 
Transport Services layer, or the Network Media Services 
layer.) Within the Communications Services layer, encryp- 
45 lion occurs at the top of the protocol stack and is typically 
performed within an application (e.g., an e-mail application, 
a Web browser). This is an end-to-end approach that can 
leave the remainder of the protocol stack (i.e., the Transport 
services and the Network Media services) unaffected. 
50 Encryption has two main components: the encryption 
algorithm, which is the series of steps that is performed to 
transform the original data; and the key, which is used by the 
algorithm in some way to encrypt the message. Typically, 
the algorithm is widely known, while the key is kept secret. 
55 There are several types of encryption in use today, including: 
Secret key cryptography — uses one key (the secret key) 
both to encrypt the message on one side and to decrypt 
the message on the other side. 
Public key cryptography — uses two keys, the public key 
60 and the private key. The public key and private key are 
mathematically related so that a message encrypted 
with the recipient's public key may be decrypted with 
the recipient's private key. Therefore, the public key 
can be widely published, while the private key is kept 
65 secret. 

There are also varying methods of employing encryption 
types described above to encrypt data sent across a network: 
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Data link layer — data is encrypted before it is placed on 
the wire. Data link encryptors are generally hardware 
products. 

Application layer — data is encrypted by the application. 

Netscape's Secure Sockets Layer (SSL) is one example 

of application-layer encryption for WWW browsers. 

SSL uses RSA encryption to wrap security information 

around TCP/IP based protocols. 
Network layer — data is encrypted inside the network 

layer header, therefore relying on the network layer 

protocol. 
Implementation Considerations 

The advantage of SSL over S/HTTP is that SSL is not 
restricted to HTTP but can also be used for securing other 
TCP/IP based services such as FTP, Telnet, etc. SSL can 
provide session level data encryption and authentication to 
enable secure data communications over public networks 
such as the Internet. 

The need for Encryption Services is particularly strong 
where electronic commerce solutions that involve exchang- 
ing sensitive or financial data are to be deployed over public 
networks such as the Internet. Cryptography can be used to 
achieve secure communications, even when the transmission 
media (for example, the Internet) is untrustworthy. Encryp- 
tion Services can also be used to encrypt data to be stored 
(e.g., sensitive product information on a sales person's 
laptop) to decrease the chance of information theft. 

There are complex legal issues surrounding the use of 
encrypting in an international environment. The US govern- 
ment restricts what can be exported (in terms of encryption 
technology), and the French government defines encryption 
technology as a "weapon of war" with appropriate legal and 
regulatory restrictions. This is a key issue in international 
e -commerce today. 
Possible Product Options 

Netscape's Secure Sockets Layer (SSL); S-HTTP; e-mail 
encryption; S-MIME 

Encryption that is architected into Web-based solutions 
Netscape's Secure Sockets Layer (SSL) — provides 

encryption for World Wide Web browsers. 
S-HTTP — a secure version of the HTTP data transfer 
standard; used in conjunction with the World Wide 
Web. 

Encryption that is embedded in e-mail products 
e-mail encryption — products such as Lotus Notes and 
Microsoft Exchange can encrypt e-mail messages and/ 
or attachments. 
S-MIME — a secure version of the MIME e-mail standard. 
Authorization 1554 

When a user requests access to network resources, the 
Authorization service determines if the user has the appro- 
priate permissions and either allows or disallows the access. 
(This occurs after the user has been properly authenticated.) 

The following are examples of ways to implement Autho- 
rization services: 

Network Operating Systems — Authorization services are 
bundled with all network operating systems in order to 
control user access to network resources. 
Firewall Services protect sensitive resources and infor- 
mation attached to an Intxxnet network from unautho- 
rized access by enforcing an access control policy. A 
variety of mechanisms exist for protecting private 
networks including: 

Filters — World Wide Web filters can prevent users from 
accessing specified content or Internet addresses. 
Products can limit access based on keywords, net- 
work addresses, time-of-day, user categories, etc. 
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Application Proxies — An application-level proxy, or 
application-level gateway, is a robust type of fire- 
wall. (A firewall is a system that enforces an access 
control policy between a trusted internal network and 
an untrusted external network.) The application 
proxy acts at the application level, rather than the 
network level. The proxy acts as a go-between for 
the end-user by completing the user-requested tasks 
on its own and then transferring the information to 
the user. The proxy manages a database of allowed 
user actions, which it checks prior to performing the 
request. 

Servers, Applications, and Databases — Authorization can 
occur locally on a server to limit access to specific system 
resources or files. Applications and databases can also 
authorize users for specific levels of access within their 
control. (This functionality is within the Environment Ser- 
vices grouping in the execution architecture.) 
Possible Product Options 

Microsoft Windows NT; Novell Netware; UNIX; Check 
Points Firewall- 1; Raptor Systems Eagle Firewall; 
Microsoft Proxy Server; Netscape Proxy Server; Microsys- 
tem Softwares Cyber Patrol Corporate; Net Nanny Soft- 
wares Net Nanny 
Network Operating Systems 

Microsoft Windows NT, Novell Netware, UNIX, etc. 
Application Proxies 

Microsoft Proxy Server — allows for designation of who 
can access the Internet and which services they can use. 
Administrators can establish additional credentials for 
logging on, set specific dialing hours or days of the 
week, and restrict access to certain sites altogether. 
Netscape Proxy Server — high-performance server soft- 
ware for replicating and filtering access to Web content 
on the Internet or an intranet. Provides access control, 
URL filtering, and virus scanning. 
Filters 

Check Point Fire Wall- 1 — combines Internet, intranet and 
remote user access control with strong authentication, 
encryption and network address translation (NAT) services. 
The product is transparent to network users and supports 
multiple protocols. 

BorderWare Firewall — protects TCP/IP networks from 
unwanted external access as well as provides control of 
internal access to external services; supports packet 
filters and application-level proxies. 

Raptor System's Eagle Firewall 

Microsystem Software's Cyber Patrol Corporate 

Net Nanny Software's Net Nanny 
Authentication 

Authentication services verify network access requests by 
validating that users are who they claim to be. For secure 
systems, one or more authentication mechanisms can be 
used to validate authorized users and to verify which func- 
tions and data they have access to. Within the corporate 
network, authentication services are often included in direc- 
tory services products like Novell's NDS. NDS requires the 
user to have an established account and supply a password 
before access is granted to resources through the directory. 

Authentication for accessing resources across an Internet 
or intranet is not as simple and is a rapidly evolving area. 
When building e-commerce Web sites there may be a need 
to restrict access to areas of information and functionality to 
known customers or trading partners. More granular authen- 
tication is required where sensitive individual customer 
account information must be protected from other custom- 
ers. 
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Authentication can occur through various means: 
Basic Authentication — requires that the Web client supply 
a user name and password before servicing a request. 
Basic Authentication does not encrypt the password in 
any way, and thus the password travels in the clear over 
the network where it could be detected with a network 
sniffer program or device. Basic authentication is not 
secure enough for banking applications or anywhere 
where there may be a financial incentive for someone 
to steal someone's account information. Basic authen- 
tication is however the easiest mechanism to setup and 
administer and requires no special software at the Web 
client. 

ID/Password Encryption — offers a somewhat higher level 
of security by requiring that the user name and pass- 
word be encrypted during transit. The user name and 
password are transmitted as a scrambled message as 
part of each request because there is no persistent 
connection open between the Web client and the Web 
server. 

Digital Certificates or Signatures — encrypted digital keys 
that are issued by a third party "trusted" organization 
(i.e. Verisign); used to verify user's authenticity. 
Hardware tokens — small physical devices that may gen- 
erate a one-time password or that may be inserted into 
a card reader for authentication purposes. 
Virtual tokens — typically a file on a floppy or hard drive 

used for authentication (e.g. Lotus Notes ID file). 
Biometric identification — the analysis of biological char- 
acteristics to verify individuals identify (e.g., 
fingerprints, voice recognition, retinal scans). 
Related to authentication, non-repudiation is a means of 
tagging a message in order to prevent an entity from denying 
that it sent or received the message. 
Possible Product Options 

Microsoft Windows NT; Novell NetWare; UNIX; Plati- 
num Technologies AutoSecure SSO; Axents Enterprise 
Access Control for Windows 95; SecurlD; Racals TrustMe 
Authentication Server; Visionics Facelt; Sensars Irisldent; 
Keyware Technologies Voice Guardian; National Registrys 
NRIdentity; Kerberos; VeriSign 

The following are examples of products that perform 
authentication: 

user IDs and passwords 

operating systems: Microsoft Windows NT, Novell 

NetWare, UNIX, etc. 
application level user IDs and passwords (e.g., e-mail 

system) 

single sign-on software — manages user logins to mul- 
tiple systems or resources. 
Platinum Technologies' AutoSecure SSO 

add-on administration packages — enhance the capa- 
bilities of native operating system security 
Axent's Enterprise Access Control for Windows 
95 — enforces password standards and encrypts data. 
Hardware Tokens 

Security Dynamics' SecurlD Authentication Tokens 
Racal's TrustMe Authentication Server 
Biometric Security 

Visionics' Facelt — face recognition 
Sensar's Irisldent — iris identification 
Keyware Technologies' Voice Guardian — voice recogni- 
tion 

National Registry's NRIdentity — fingerprint recognition 
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Keys and Certificates 

Kerberos — an encryption and key management protocol 
for third party authorization; vendors include Cyber- 
SAFE and Digital Equipment Corporation. 
VeriSign — a company that manages digital certificates. 

Communication Fabric 1010 

As communication networks become increasingly com- 
plicated and interconnected, the services provided by the 
network itself have by necessity increased as well. Clients 
and servers are rarely directly connected to one another, but 
separated by a network of routers, servers and firewalls 
providing an ever increasing number of network services 
such as address resolution, message routing, security screen- 
ing and many more. 

The communications fabric provides common network 
services to the platform-specific network services residing 
on the client and server nodes. These common network 
services can be used to manage resources and translate 
capabilities within and across enterprises. 

Short of interpreting the data being transmitted, the com- 
munications fabric is aware of the different message - 
oriented information streams in order to help the client and 
server communicate regardless of the different network 
functions implemented on each platform. 

An intelligent communications fabric monitors and routes 
data flows and provides functionality (security, directories, 
etc.) to clients and servers. An intelligent communications 
fabric provides the following benefits: 

An intelligent network can manage itself, including 
addressing, routing, security, recovery, etc. It is ineffi- 
cient for individual clients and servers to perform such 
tasks. 

Specialized network components reduce the network- 
related processing that occurs on clients and servers. 
An intelligent network integrates heterogeneous clients, 
servers, and other resources by resolving incompatible 
protocols and standards. 
An intelligent network has the capability to actively 
manage the flow of information rather than simply 
moving data. This allows the network to effectively 
deliver multimedia and other network-sensitive traffic. 
An intelligent network adds value to enterprise resources 
by presenting a cohesive view of available resources 
and increasing the level of security associated with 
those resources. 
FIG. 24 illustrates various components of the Communi- 
cation Fabric. 
Transport Services 2402 

Provides the underlying protocols responsible for trans- 
mitting and securing data communications. Transport Ser- 
vices are responsible for establishing, maintaining and ter- 
minating end-to-end communications between users and 
processes. Connection management provides transfer ser- 
vices that ensure the delivery of data from sender to receiver, 
which support the transferring of messages from a process 
running on one machine to a process running on another 
machine. In addition, connection management provides ser- 
vices that initiate a connection, gracefully terminate a 
connection, and handle abrupt termination. These services 
take place for application before and after the data is 
formatted for transport over the network. 
Messaging Transport 2404 

The Message Transport service is responsible for the 
end-to-end delivery of messages. It can include the follow- 
ing functionality: 
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End-to-End Data Transfer — The Message Transport Ser- 
vice formats messages for sending and confirms the 
integrity of received messages. 

Connection Control — The Message Transport service 
may establish end-to-end (client-server) connections 
and track addresses and other associated information 
for the connection. The service also tears down con- 
nections and handles hard connection failures. 

Reliable Transfer — The Message Transport service may 
manage reliable delivery of messages through the use 
of acknowledgments and retransmissions. 

Flow Control — The Message Transport service may allow 
the receiver to govern the rate at which the sender 
transfers data. 

Multiplexing — The Message Transport service may 
define multiple addresses or ports within a single 
network node, allowing multiple processes on the node 
to have their own communications paths. 
(Some transport services do not implement all of the listed 
functionality. For example, the UDP protocol does not offer 
connection control or reliable transfer.) 

The following are examples of protocols that provide 
message transport: 

SPX (Sequenced Packet eXchange) 
TCP (Transmission Control Protocol) 
UDP (User Datagram Protocol) 

NetBIOS/NetBEUI (Network Basic Input/Output 
System/NetBIOS Extended User Interface) 

APPC (Advanced Program -to-Program Communications) 

AppleTalk 
Packet Forwarding/Internetworking 2406 

The Packet Forwarding/Internetworking service transfers 
data packets and manages the path that data takes through 
the network. It includes the following functionality: 

Fragmentation/Reassembly — The Packet Forwarding/ 
Internetworking service divides an application message 
into multiple packets of a size suitable for network 
transmission. The individual packets include informa- 
tion to allow the receiving node to reassemble them 
into the message. The service also validates the integ- 
rity of received packets and buffers, reorders, and 
reassembles packets into a complete message. 

Addressing — The Packet Forwarding/Internetworking 
service encapsulates packets with addressing informa- 
tion. 

Routing — The Packet Forwarding/Internetworking ser- 
vice can maintain routing information (a view of the 
network topology) that is used to determine the best 
route for each packet. Routing decisions are made 
based on the cost, percent utilization, delay, reliability, 
and similar factors for each possible route through the 
network. 

Switching — Switching is the process of receiving a 
packet, selecting an appropriate outgoing path, and 
sending the packet. Switching is performed by routers 
and switches within the communications fabric. 
Switching can be implemented in the following ways: 
For some network protocols (e.g., IP), routers draw 
upon dynamic routing information to switch packets 
to the appropriate path. This capability is especially 
important when connecting independent networks or 
subnets. 

For other network protocols (e.g., Ethernet, Token 
Ring), switching simply directs packets according to 
a table of physical addresses. The switch can build 
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the table by "listening" to network traffic and deter- 
mining which network nodes are connected to which 
switch port. 

Some protocols such as Frame Relay involve defining 
5 permanent routes (permanent virtual circuits PVCs) 

within the network. Since Frame Relay is switched 
based upon PVCs, routing functionality is not 
required. 

Multicasting — The Packet Forwarding/Internetworking 
10 service may support multicasting, which is the process 
of transferring a single message to multiple recipients 
at the same time. Multicasting allows a sender to 
transfer a single copy of the message to the communi- 
cations fabric, which then distributes the message to 
15 multiple recipients. 

The following are examples of protocols that provide 
Packet Forwarding/Internetworking: 
IP (Internet Protocol) 
20 IP Multicast (emerging standard that uses a special range 
of IP addresses to instruct network routers to deliver 
each packet to all users involved in a multicast session) 
IPX (Internetwork Packet Exchange) 
ATM (Asynchronous Transfer Mode) 
25 Frame Relay 
X.25 

SMDS (Switched Multimegabit Data Service) 
The following are examples of network components that 
30 perform Packet Forwarding/Internetworking: 
routers 
switches 

ATM switches, Frame Relay switches, IP switches, Eth- 
ernet switches, Token Ring switches, etc. 
35 The following are examples of protocols that maintain 
routing information tables within routers: 
Distance Vector Protocols — each router periodically 
informs neighboring routers as to the contents of rout- 
ing table (destination addresses and routing metrics); 
40 routing decisions based on the total distance and other 
"costs" for each path. 

IP and IPX Routing Information Protocols (RIP) 
AppleTalk Routing Table Management Protocol 
(RTMP) 

Ciscos Interior Gateway Routing Protocol (IGRP) and 

Enhanced IGRP 
Link-State Protocols — each router periodically broad- 
casts changes to the routers and directly attached net- 
works that it can talk with. 
Open Shortest Path First (OSPF) 
ISOs Intermediate System to Intermediate System (IS- 

IS) 

Novells NetWare Link Services Protocol (NLSP) 
55 Policy Routing Protocols — allow Internet backbone rout- 
ers to accept routing information from neighboring 
backbone providers on the basis of contracts or other 
non-technical criteria; routing algorithms are Distance 
Vector. 

60 Border Gateway Protocol (BGR) 

Interdomain Routing Protocol (IDR) 
Circuit Switching 2408 

While Message Transport services and Packet 
Forwarding/Internetworking services support the transfer of 
65 packetized data, Circuit Switching services establish physi- 
cal circuits for the transfer of circuit-switched voice, fax, 
video, etc. 
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Circuit Switching 
uses an end-to-end physical connection between the 
sender and the receiver that lasts for the duration of the 
"call" 

includes voice, video, fax, etc. 

includes data in a circuit switched architecture (e.g., 
dial-up connections) 
Packetized 

transferred through brief, temporary, logical connections 

between nodes 
includes data and packetized multimedia (video, voice, 

fax, etc.) 

Circuit Switching includes the following functionality: 
establishes end-to-end path for circuit (may involved 

multiple intermediate nodes/switches) 
manages end-to-end path (quality, billing, termination, 

etc.) 

The following are examples of Circuit Switching: 

analog dial-up telephone circuit 

ISDN (Integrated Services Digital Network) 
Possible Product Options 

Lucent's Definity; Nortels Meridian; Lucents ESS; 
Nortels DMS; Tellabs Titan products; Lucents DSX prod- 
ucts; Alcatels SX products; AltiGens AltiServ; Lucents 
Internet Telephony Server 

The following are examples of PBX products, which 
perform circuit switching within private telephone net- 
works: 

Lucent's Definity 

Nortel's Meridian 

The following are examples of central office (telephone 
company) switches, which perform circuit switching within 
the public telephone network: 

Lucent's ESS 

Nortel's DMS 

The following are examples of Digital Access Cross- 
connect Systems (DACS), which are configured to switch 
circuits among multiple ports. 

Tellabs' Titan products 

Lucent's DSX products 

Alcatel's SX products 

The following is an example of a PC-based PBX system: 

AltiGen's AltiServ — PC-based PBX system for a small 
branch office or a low-volume specialized call center. 

The following is an example of a circuit-switching/ 
packet-forwarding gateway: 

Lucent's Internet Telephony Server — server software that 
routes calls from PBXs over the Internet or intranets. 
Transport Security 2410 

Transport Security services (within the Transport Services 
layer) perform encryption and filtering. 
Transport-layer Encryption 

Encryption within the Transport Services layer is per- 
formed by encrypting the packets generated by higher level 
services (e.g., Message Transport) and encapsulating them 
in lower level packets (e.g., Packet Forwarding/ 
Internetworking). (Note that encryption can also occur 
within the Communications Services layer or the Network 
Media layer.) Encryption within the Transport Services layer 
has the advantage of being independent of both the appli- 
cation and the transmission media, but it may make network 
monitoring and troubleshooting activities more difficult. 

The following standards support transport-layer encryp- 
tion: 
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Point to Point Tunneling Protocol 
Layer 2 Tunneling Protocol 
Transport-layer Filtering 

Network traffic can be controlled at the Transport Services 
5 layer by filtering data packets based on source and/or 
destination addresses and network service. This ensures that 
only authorized data transfers can occur. This filtering is one 
of the roles of a packet filtering firewall. (A firewall is a 
system that enforces an access control policy between a 
10 trusted internal network and an untrusted external network.) 
The following IETF standard supports interoperability 
among security systems: 

IPSec Allows two nodes to dynamically agree on a 
security association based on keys, encryption, authen- 
15 tication algorithms, and other parameters for the con- 
nection before any communications take place; oper- 
ates in the IP layer and supports TCP or UDP. IPSec 
will be included as part of IPng, or the next generation 
of IP. 

20 Implementation Considerations 

Firewalls can also provide a single point of access to the 
companys network, which could be used to maintain an 
audit trail. Some firewalls provide summaries to the admin- 
istrator about the type of traffic and amount of traffic passed 
25 through it, number of break in attempts, etc. 

Most commercial firewalls are configured to reject all 
network traffic that has not been explicitly allowed, thus 
enforcing the policy, Only allow traffic that has been cat- 
egorically permitted, otherwise prohibit. This policy pro- 
30 vides much more control and is much safer than a policy 
which allows traffic unless it has been explicitly prohibited. 
Possible Product Options 

Cisco Systems; Bay Networks; 3Com Corp.; Check 
Points Firewall- 1; Raptor Systems Eagle Firewall; Data 
35 Fellows F-Secure VPN; Racals Datacryptor 64F 

The following are examples of vendors of products that 
perform Transport-level encryption: 
routers: 

Cisco Systems 
40 Bay Networks 
3Com Corp. 
firewalls: 

Check Point's Firewall-1 
45 Secure Computing's BorderWare Firewall Server 
Raptor Systems' Eagle Firewall 
encryption devices: 

Data Fellows' F-Secure VPN 
Racal's Datacryptor 64F 
50 The following are examples of products that perform 
Transport-level packet filtering: 
firewalls: 

Check Point FireWall-1 — combines Internet, intranet 
and remote user access control with strong 
55 authentication, encryption and network address 

translation (NAT) services. The product is transpar- 
ent to network users and supports multiple protocols. 
Secure Computing's BorderWare Firewall Server pro- 
tects TCP/IP networks from unwanted external 
60 access as well as provides control of internal access 

to external services; supports packet filters and 
application-level proxies. 
Raptor Systems' Eagle Firewall 
routers: 
65 Cisco Systems 
Bay Networks 
3Com Corp. 
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Network Address Allocation 2412 

Network Address Allocation services manage the distri- 
bution of addresses to network nodes. This provides more 
flexibility compared to having all nodes assigned static 
addresses. This service assigns addresses to nodes when they 5 
initially power-on and connect to the network. 

The following are examples of standards that implement 
Network Address Allocation and allow a network node to 
ask a central resource for the node_s network address (e.g., 
IP address): 10 

DHCP (Dynamic Host Configuration Protocol) 

BootP (Bootstrap Protocol) 
Quality of Service 2414 

Different types of network traffic (e.g., data, voice, video) 
have different quality of service requirements. For example, 15 
data associated with video conferencing sessions is useless 
if it is not delivered "on time". On the other hand, traditional 
best-effort data services, such as file or e-mail transfer, are 
not affected by variations in latency. QoS (Quality of 
Service) services deliver a defined network throughput for 20 
designated traffic by allocating dedicated bandwidth, priori- 
tizing data traffic, etc. (Note that as an alternative to pre- 
defined throughput, some QoS protocols can also offer a best 
effort (i.e., variable) throughput QoS based on available 
network capacity.) 25 

The following list provides a description of various Qual- 
ity of Service parameters. 

connection establishment delay — time between the con- 
nection request and a confirm being received by the ^ 
requester 

connection establishment failure probability — chance that 
the connection will not be established within the maxi- 
mum establishment delay 
throughput — bits per second (bps) of transmitted data 35 
transit delay — time elapsed between when sender trans- 
fers packet and recipient receives packet 
residual error rate — number of lost or corrupted messages 

compared to total messages in the sampling period 
transfer failure probability — the fraction of the time when 40 
the throughput, transit delay, or residual error were not 
those agreed upon at the start of the connection 
connection release delay — time between when one node 
initiates a release and the other node performs the 
release 45 
connection release failure probability — fraction of release 

attempts which do not succeed 
protection — specifies a secure connection 
priority — indicates traffic priority over the connection 50 
resilience — probability that the transport layer spontane- 
ously terminates 
QoS can be achieved in various ways as listed below: 
Specialized QoS Communications Protocols — provide 
guaranteed QoS, 55 
Asynchronous Transfer Mode (ATM) — ATM is a 
connect ion -oriented wide area and local area net- 
working protocol that delivers QoS on a per- 
connection basis. QoS is negotiated as part of the 
initial connection set up and as network conditions 60 
change. Because of the small size of ATM data cells, 
QoS can be better managed, compared to protocols 
such as Ethernet that have large frames that can tie 
up network components. For ATM to deliver QOS to 
applications, ATM must be used end-to-end. 65 
Resource Reservation Protocol (RSVP) — The emerg- 
ing RSVP specification, proposed by the Internet 
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Engineering Task Force (IETF), allows applications 
to reserve router bandwidth for delay-sensitive sen- 
sitive IP traffic. With RSVP, QoS is negotiated for 
each application connection. RSVP enables the net- 
work to reserve resources from end to end, using 
Frame Relay techniques on Frame Relay networks, 
ATM techniques on ATM, and so on. In this way, 
RSVP can achieve QoS across a variety of network 
technologies, as long as all intermediate nodes are 
RS VP-capable. 
IP Stream Switching — improves network performance 
but does not guarantee QoS. 

IP Switching — IP Switching is an emerging technology 
that can increase network throughput for streams of 
data by combining IP routing software with ATM 
switching hardware. With IP Switching, an IP switch 
analyzes each stream of packets directed from a 
single source to a specific destination, and classifies 
it as short- or long-lived. Long-lived flows are 
assigned ATM Virtual Channels (VCs) that bypass 
the IP router and move through the switching fabric 
at the full ATM line speed. Short-lived flows con- 
tinue to be routed through traditional store-and- 
forward transfer. 

Tag Switching — Like IP Switching, emerging Tag 
Switching technology also improves network 
throughput for IP data streams. Tag Switching aggre- 
gates one or more data streams destined for the same 
location and assigns a single tag to all associated 
packets. This allows routers to more efficiently trans- 
fer the tagged data. Tag Switching is also known as 
Multiprotocol Label Switching. 
Data Prioritization — improves network performance but 

does not guarantee 

While not an example of end-to-end QoS, various 
network components can be configured to prioritize 
their handling of specified types of traffic. For 
example, routers can be configured to handle legacy 
mainframe traffic (SNA) in front of other traffic (e.g., 
TCP/IP). A similar technique is the use of prioritized 
circuits within Frame Relay, in which the Frame 
Relay network vendor assigns different priorities to 
different permanent virtual circuits. 
Prioritization techniques are of limited effectiveness if 
data must also pass through network components 
that are not configured for prioritization (e.g., net- 
work components run by third party network 
providers). 
Network Media Services 2416 

The Network Media layer provides the following capa- 
bilities: 

Final framing of data for interfacing with the physical 
network. 

Performing, receiving, interpreting and acting on signals 
from the communications fabric. 

Transferring data through the physical network. 

The technologies used at the Network Media Services 
layer vary depending on the type of network under consid- 
eration. 

Media Access 2418 

Media Access services manage the low-level transfer of 
data between network nodes. Media Access services per- 
form the following functions: 

Physical Addressing — The Media Access service encap- 
sulates packets with physical address information used 
by the data link protocol (e.g., Ethernet, Frame Relay). 
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Packet Transfer — The Media Access service uses the data 
link communications protocol to frame packets and 
transfer them to another computer on the same 
network/subnetwork. 

Shared Access — The Media Access service provides a 5 
method for multiple network nodes to share access to a 
physical network. Shared Access schemes include the 
following: 

CSMA/CD — Carrier Sense Multiple Access with Col- 
lision Detection. A method by which multiple nodes 10 
can access a shared physical media by "listening" 
until no other transmissions are detected and then 
transmitting and checking to see if simultaneous 
transmission occurred. 

token passing — A method of managing access to a 15 
shared physical media by circulating a token (a 
special control message) among nodes to designate 
which node has the right to transmit. 

multiplexing — A method of sharing physical media 
among nodes by consolidating multiple, independent 20 
channels into a single circuit. The independent chan- 
nels (assigned to nodes, applications, or voice calls) 
can be combined in the following ways: 
time division multiplexing (TDM) — use of a circuit 
is divided into a series of time slots, and each 25 
independent channel is assigned its own periodic 
slot. 

frequency division multiplexing (FDM) — each inde- 
pendent channel is assigned its own frequency 
range, allowing all channels to be carried simul- 30 
taneously. 

Flow Control — The Media Access service manages the 
flow of data to account for differing data transfer rates 
between devices. For example, flow control would have 

. . . 35 

to limit outbound traflic if a receiving machine or 
intermediate node operates at a slower data rate, pos- 
sibly due to the use of different network technologies 
and topologies or due to excess network traffic at a 
node. 

40 

Error Recovery — The Media Access service performs 
error recovery, which is the capability to detect and 
possibly resolve data corruption that occurs during 
transmission. Error recovery involves the use of 
checksums, parity bits, etc. 45 

Encryption — The Media Access service may perform 
encryption. (Note that encryption can also occur within 
the Communications Services layer or the Transport 
Services layer.) Within the Network Media Services 
layer, encryption occurs as part of the data link protocol 50 
(e.g. Ethernet, frame relay). In this case, all data is 
encrypted before it is placed on the wire. Such encryp- 
tion tools are generally hardware products. Encryption 
at this level has the advantage of being transparent to 
higher level services. However, because it is dependent 55 
on the data link protocol, it has the disadvantage of 
requiring a different solution for each data link proto- 
col. 

The following are examples of Media Access protocols: 
Ethernet 60 
token ring 
FDDI 

portions of the ATM standard 

HDLC/SDLC 65 
LAPB 

T-carrier, E-carrier (e.g., Tl, T3, El, E3) 
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TDM and FDM (Time Division Multiplexing and Fre- 
quency Division Multiplexing; used on T-carriers, etc.) 
SONET, SDH 
PPP, SLIP 

V.32, V.34, V.34 bis, etc. 
RS-232, EIA-232 

TDMA and FDMA (Time Division Multiple Access and 
Frequency Division Multiple Access; used on wireless 
links) 

Specialized services convert between addresses at the 
Media Access level (i.e., physical addresses like Ethernet) 
and the Packet Forwarding/Internetworking level (i.e., net- 
work addresses like IP). The following protocols are 
examples of this functionality: 
ARP (Address Resolution Protocol) — allows a node to 
obtain the physical address for another node when only 
the IP address is known. 
RARP (Reverse Address Resolution Protocol) — allows a 
node to obtain the IP address for another node when 
only the physical address is known. 
Possible Product Options 

Semaphores Network Security System for Workgroups 
Semaphore's Network Security System for 
Workgroups — encrypts Ethernet. 

Physical Media 2420 

As illustrated in FIG. 25, the Physical Media is divided 

into two categories: 

1) . the physical connectors 2502 

2) . the physical media (wired or wireless) 2504 
Physical Connectors 

The following are examples of wiring connectors used to 
connect network nodes to physical media: 
RJ-11, RJ-45 
BNC 

DB-9, DB-25 

fiber optic connectors 
Physical Media 

Physical Media may be wired or wireless. Wired Physical 
Media includes wiring and cabling, while wireless Physical 
Media includes antennas, connectors, and the radio fre- 
quency spectrum. 

The following are examples of wired physical media: 

twisted pair wiring, shielded twisted pair wiring 

coaxial cable 

fiber optic cable 

4-pair voice-grade wiring 

The following are examples of wireless physical media: 
cellular antennas and the associated radio frequencies 
wireless local area network antennas and the associated 

radio frequencies 
satellite antennas and the associated radio frequencies 

Transaction 1012,1014 

A transaction is a unit of work that has the following 
(ACID) characteristics: 

A trans action is atomic; if interrupted by failure, all 
effects are undone (rolled back). 

A transaction produces consistent results; the effects of a 
transaction preserve invariant properties. 

A transaction is isolated; its intermediate states are not 
visible to other transactions. Transactions appear to 
execute serially, even if they are performed concur- 
rently. 
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A transaction is durable; the effects of a completed 
transaction are persistent; they are never lost (except in 
a catastrophic failure). 
A transaction can be terminated in one of two ways: the 
transaction is either committed or rolled back. When a 
transaction is committed, all changes made by the associated 
requests are made permanent. When a transaction is rolled 
back, all changes made by the associated requests are 
undone. 

Transaction Services provide the transaction integrity 
mechanism for the application. This allows all data activities 
within a single business event to be grouped as a single, 
logical unit of work. 

In small to moderate scale environments of less than 150 
simultaneous users on a single server, this service may be 
provided by the DBMS software with its restart/recovery 
and integrity capabilities. 

For larger client/server environments distributed on-line 
transaction managers might be more applicable. These trans- 
action managers provide sharing of server processes across 
a large community of users and can be more efficient than 
the DBMSs, 

FIG. 26 illustrates several of the components of the 
Transaction areas of the Netcentric Architecture Framework, 
each of which will be discussed in more detail below. 
Transaction Monitor 2602 

The Transaction Monitor Services are the primary inter- 
face through which applications invoke Transaction Ser- 
vices and receive status and error information. Transaction 
Monitor Services, in conjunction with Information Access 
and Communication Services provide for load balancing 
across processors or machines and location transparency for 
distributed transaction processing. 
Implementation Considerations 
Does the system access nonrelational data? 

Some TP monitors provide a method of accessing non- 
relational data, such as VSAM files or flat files, indepen- 
dently of where the file physically resides. If write access is 
required for these data sources, a TP monitor would provide 
more dependable messaging and two-phase commit capa- 
bilities than the data source messaging capabilities alone. 
Does the system require high throughput? 

Because TP monitors provide load balancing functionality 
and because they effectively reduce the number of connec- 
tions that must be made to the database(s), they will help 
conserve the resources of the data servers and, as a result, 
increase the throughput of the system. Systems with high 
throughput requirements should consider using a TP moni- 
tor. 

Do the on-line applications need the support of interoper- 
ability between autonomous, heterogeneous processors? 

Some TP monitors are available on multiple platforms and 
maintain interoperability (communication, data translation, 
etc.) between heterogeneous resource managers (databases) 
and clients (UNIX, MS Windows NT, etc.). For this reason, 
projects that intend to support a heterogeneous hardware 
environment should consider using a TP monitor. 
Is the system supposed to be highly available (i.e. 24x7), or 
mission critical? 

TP monitors offer robust functionality: two-phase 
commit, recovery/rollback, naming services, security 
services, can guarantee message delivery, can be maintained 
for high-availability operation and provides audit trail log- 
ging. Therefore, the more mission critical the system, the 
more likely it is that a TP monitor should be used. 
Does the system require high availability? 

Because of their fault tolerance, TP monitors make a 
valuable addition to systems that require high availability. 
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The automatic restart/recovery feature helps a system rec- 
ognize when components have failed and attempts to restart 
them. Also, because of the location transparency feature of 
service calling, if an entire node in a system goes down, 

5 clients may be able to reach the service they need on another 
node providing the same service. 
Will the system be scaled in the future? 

TP monitors offer multiple scalability options. TP moni- 
tors can run on machines ranging from PCs to mainframes. 

10 Monitors also scale by allowing new machines to be added 
dynamically to the system. Adding additional nodes in the 
production cycle is one TP monitor strength, although some 
monitors are better at doing this than others. If it is antici- 
pated that system volumes will increase during the system's 

15 lifetime, scalability in itself is an excellent reason to use a TP 
monitor. 

Does the system have complex security requirements? 

All of the TP monitors available today provide security 
authorization/authentication services. Most of them utilize 

20 the Kerberos security package, developed at the Massachu- 
setts Institute of Technology (MIT). 
Does the system access legacy systems? 

TP monitors can access databases and services running on 
mainframe systems. TP monitors frequently include main- 

25 frame networking capability and maintain transaction roll- 
back during mainframe accesses. If access to the legacy 
system is read only, the messaging capabilities of the data 
source will probably be sufficient. If access is write, 
however, the messaging and two -phase commit capabilities 

30 of the TP monitor would be more dependable. 
Is the system distributed across multiple nodes? 

TP monitors provide common administrative facilities to 
manage groups of servers. These facilities allow a system to 
be managed from one location with a common set of 

35 commands for each machine. 

How many users access the system concurrently? 

Different sources give different answers as to the Dumber 
of concurrent users that necessitates the use of a TP monitor. 
The monitor vendors themselves give low values; the data- 

40 base vendors give high values. The middle ground seems to 
be somewhere around 250 users. This is by no means 
definitive, however; weigh each of the following questions 
when making the choice. 

Do the on-line applications access/update more than one 
45 database or more than one type of database? 

The real strength of TP monitors is their ability to ensure 
a global two-phase commit over multiple, heterogeneous 
databases. A system that has this quality is a candidate for a 
TP monitor. 

50 Is the system not a transaction processing system? 

Although TP monitors provide global two -phase commit 
"transaction processing" functionality, systems that do not 
need this feature can also benefit by using TP monitors. For 
example, the load-balancing feature in itself can help 

55 increase system performance. Also, the administrative facili- 
ties can help simplify system management. 
Is Data Dependent Routing Necessary? 

Data Dependent Routing is the ability to route requests to 
a particular server based upon the data passed within the 

60 request. TP monitors can provide this functionality, e.g. A 
system has several servers accepting requests from clients 
dispersed across North America. There are two groups of 
servers. One group of servers handles requests from all 
clients located in the USA while the other group serves 

65 requests from Canada. When a client sends a request to the 
system, a field in the request message, defining the location 
of the client, is passed to the system. The TP monitor is then 
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able to route the request to the correct group of servers (USA 
or Canada) based upon information in the request message. 
Is Reliable Queueing Necessary? 

TP monitors provide the ability to enqueue and dequeue 
requests to and from a reliable (stable storage) queue. Both 5 
the application and the administrator can control the order of 
the messages (service requests) in the queue. Messages can 
be ordered LIFO, FIFO, time based, priority, or by some 
combination of these keys. 

Example 10 

A system updates a customer database. Suppose that the 
database has been partitioned such that the information on 
customers most likely to use a branch office is stored locally 
at a branch office. There is a requirement to maintain an 
up-to-date of the entire customer database at the home office, is 
The application that updates the local customer master can 
place a copy of the update into a reliable queue. The queue 
can be forwarded to the home office via a WAN, and the 
updates can be replicated in the home office database. The 
queuing system can be used to assure that every update 20 
completed at the local office is completed at the home office. 
Is The System Multi-tiered? 

Transaction Services are typically used in three -tier and 
multi-tier architectures. Particularly in Netcentric 
environments, applications might need to support getting 25 
and providing access to multiple back-end services, across 
enterprises, as part of a single transaction or user activity. 
This can be especially challenging if the user does not own 
some or all of the back-end services and/or data that its 
application relies on. 30 
Product Considerations 

Is the client interested in stable or emerging technologies? 

TUXEDO has been in the TP marketplace for seven years 
and has the most installations of all TP monitors. Encina, 
TOP END, and CICS/6000 are relatively new and emerging. 35 
Does the client plan to use Windows NT? 
On Which platforms/operating systems do the servers run? 

TP monitor support for NT may be limited. 

Some TP monitors are capable of running on a wider 
variety of platforms/operating systems than others. 40 
Is the project installing a new system or rehosting/ 
downsizing an existing mainframe system? 

The UniKix, VIS/TP, and CICS/6000 monitors were 
developed specifically with rehosting in mind. TUXEDO, 
Encina, and TOP END are best suited to fresh installations. 45 
Does the system use PC-based clients? 

Each TP monitor offers different support for PC-based 
clients. TUXEDO and TOP END currently provide DOS, 
Windows, and OS/2 application programming interface 
(API) support. Encina offers PC support, but this feature is 50 
still in beta test. Several vendors have PowerBuilder and 
Visual Basic interfaces planned for their monitors, but as of 
this practice aid's printing, nothing has been released. 
On which platforms will client applications execute? 

New and re-engineered systems may be required to 55 
execute on a previously installed base of clients. 
Does the system require integration with other 3rd party 
tools? 

The client may expect the TP monitor to integrate with an 
already installed base of 3rd party development tools. 60 
Does the system require mainframe connectivity? 

Of the four monitors that are evaluated in this practice aid, 
all of them offer varying levels of mainframe connectivity. 
Does the client have existing personnel with mainframes — 
CICS experience? 65 

CICS/6000 has a programming interface similar to main- 
frame CICS. The learning curve for mainframe CICS pro- 
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gram me rs to use CICS/6000 would be minimal; for these 
same personnel to program using TUXEDO, Encina, or TOP 
END, the learning curve would be substantial. On the other 
hand, because CICS/6000's administrative facilities are not 
similar to mainframe CICS, administrative personnel will 
face a steep learning curve: they will need to learn UNIX, 
DCE, and Encina (the layers on which CICS/6000 is built). 
(NOTE: VIS/TP and UniKix are also implementations of 
CICS in the UNIX environment, but they ere not included in 
this evaluation.) 
Possible Product Options 

Tuxedo; CICS/6000; Encina; MS Transaction Server; 
Sybase Jaguar; TOP END; openUTM; TransIT Open/OLTP 
Below are commonly used transaction monitors: 
BEA TUXEDO — provides a robust middleware engine 
for developing and deploying business-critical client/ 
server applications. BEA TUXEDO handles not only 
distributed transaction processing, but also application 
and the full complement of services necessary to build 
and run enterprise-wide applications. It enables devel- 
opers to create applications that span multiple hardware 
platforms, databases and operating systems. 
IBMs CICS/6000 — an application server that provides 
industrial-strength, online transaction processing and 
transaction management for mission-critical applica- 
tions on both IBM and non-IBM platforms. CICS 
manages and coordinates all the different resources 
needed by applications, such as RDBMSs, files and 
message queues to ensure completeness and integrity of 
data. 

Transarcs Encina — implements the fundamental services 
for executing distributed transactions and managing 
recoverable data, and various Encina extended 
services, which expand upon the functionality of the 
toolkit to provide a comprehensive environment for 
developing and deploying distributed transaction pro- 
cessing. 

Microsofts Transaction Server (Viper) — a component- 
based transaction processing system for developing, 
deploying, and managing high performance, and scal- 
able enterprise, Internet, and intranet server applica- 
tions. Transaction Server defines an application pro- 
gramming model for developing distributed, 
component-based applications. It also provides a run- 
time infrastructure for deploying and managing these 
applications. 
Brief Product Considerations 

Encina— The Encina DTP (OLTP) was built on top of 
OSFs DCE. This is both its greatest asset and curse. 
DCE offers a very complete set of functions including 
security services, RPCs, a directory service (like a 
yellow pages for clients to find services) and a standard 
time service, and it is truly cross-platform and is 
endorsed by most vendors. The problem is that it is a 
resource hog, and is fairly slow. DCE is also somewhat 
immature in that there are not many tools to help you 
administer or program applications (although many are 
on the way). Encina adds primarily a transactional 
element and some load balancing services to RPCs. It 
also provides an easier interface to work with (although 
it is still an administrative nightmare). 

The good news is that the tools are getting better all of the 
time. Also, Encina is very scalable and services can be 
on any machine in the network. Finally, Enema's load 
balancing is quite good, much belter then native DCE 
or Tuxedo. 
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1\ixedo 
Functionality 

Can handle a large number of concurrent client 
applications 

Can handle a large volume of through-put (ex. 1000+ 
TPS) 

Scaleable (handle many clients or a few without code 
rewrite) 

Supports Transactions, including XA transactions 
Has its own transaction resource manager 
Guaranteed message delivery using a stable storage 
queue (/Q) 

Future service delivery using/Q (usually for batch 
processing) 

Can prioritize messages — most important get pro- 
cessed sooner. 

Supports many platforms (all UNIX, NT, all com- 
mon client platforms) 

Tuxedo supports C, C++, and Cobol development 

Can be used for basic c/s messaging 

Supports conversational messaging between a client 
and a specific server 

Peer-to-peer, client-to-client messaging is supported 

Unsolicited messaging is supported for client pro- 
cesses 

Asynchronous:service calls can be made by client 

and server processes 
Synchronous service calls can be made by client and 

server processes 
Synchronous calls that receive no return message are 

supported 

Very good security — must connect to access services 

Security can be integrated w/Kerberos 

Has many different buffer types: view to pass C 
structs, FML to pass anything, carrays to pass 
binary (sound, video), strings to pass strings 

FML allows dynamic messages to be sent/received 

Automatic error logging for Tuxedo components 
(ULOG, tagent log) 

Application code can write to the ULOG with a 
Tuxedo API (error logging provided) 

Automatic process monitor for process that die or 
machines that get partitioned 

Service location independency (distribution/ 
directory services) 

Platform independency-handles data conversion 

Built in data compression (if desired) 

Built in performance measurement feature for ser- 
vices 

Built in admin functions to monitor Tuxedo system 

online (tmadmin) 
A server can be called based on data in the message 

(Data Dependent Routing) 
Customizable server start-up and shutdown func- 
tions are automatically called. 
/Domains allow independent Tuxedo regions to 

share services 
Extensions to execute IMS and CICS transactions 

from UNIX (Open Transport) 
Subscribe and Broadcast supported 
APIs to get admin and system monitoring data for 

custom operation tools 
JOLT (java to access Tuxedo servers) 
Other Reasons to Use Tuxedo 
Tuxedo is the market leader OLTP 
Tuxedo is a proven product used in mission critical 

systems govt, and financial) 
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Tuxedo can be used to develop highly-available 

systems (24x7) 
Has been implemented with PowerBuilder, 
VisualBasic, Motif clients, and unix batch sys- 
5 terns. 

Cons of Using Tuxedo 

Tuxedo for basic c/s messaging is overkill. 
Expensive to purchase 

Can be complicated to develop with and administer 
10 System performance tuning requires an experienced 

Tuxedo administrator 

Uses IPC resources and therefore should not be on 
same machine w/other IPC products 

Must be understood thoroughly before design starts. 
35 If used incorrectly, can be very costly. 

Single threaded servers requires an upfront packag- 
ing design. 

Difficult to debug servers 

Does not work well with Pure Software products: 
20 Purify, Quantify 

Servers must be programmed to support client con- 
text data management 
Difficult to do asynch messaging in 3rd party Win- 
dows 3.x client tools (ex. PowerBuilder) 
25 Resource Management 2604 

A Resource Manager provides for concurrency control 
and integrity for a singular data resource (e.g., a data base or 
a file system). Integrity is guaranteed by ensuring that an 
update is completed correctly and entirely or not at all. 
30 Resource Management Services use locking, commit, and 
rollback services, and are integrated with Transaction Man- 
agement Services. 
Transaction Management 2606 

Transaction Management Services coordinate transac- 
35 tions across one or more resource managers either on a 
single machine or multiple machines within the network. 
Transaction Management Services ensure that all resources 
for a transaction are updated, or in the case of an update 
failure on any one resource, all updates are rolled back. 
^ This services that allow multiple applications to share 
data with integrity. The transaction management services 
help implement the notion of a transaction — a set of com- 
putations producing changes to recoverable data which 
demonstrate the ACID properties: 
45 Atomicity — all changes are made completely 
(committed) or not at all (roll-back). 
Consistency — the effects of a transaction preserve invari- 
ant properties. 

Isolation — intermediate data values are not visible to 
50 other transactions. 

Durability — the effect of a completed transaction are 
persistent. 

Two-Phase Commit is a feature found in distributed 
database management-systems and online transaction pro- 

55 cessing (OLTP) monitors to ensure information integrity 
across distributed databases. With this feature, a transaction 
is only committed if two databases have the necessary 
information. If a problem arises on a network connection or 
a computer, the software will roll the transaction back so it 

60 will not be entered in either place. A restart mechanism may 
then retriy to complete the transaction. 
Possible Product Options 

Tuxedo; Encina; TOP END; CICS/6000; openUTM; 
TransIT Open/OLTP 

65 Transaction Partitioning 2608 

Transaction Partitioning Services provide support for 
mapping a single logical transaction in an application into 
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the required multiple physical transactions. For example, in 
a package or legacy rich environment, the single logical 
transaction of changing a customer address may require the 
partitioning and coordination of several physical transac- 
tions to multiple application systems or databases. Transac- 
tion Partitioning Services provide the application with a 
simple single transaction view. 
Implementation Considerations 

Must the system support logical transactions that occur 
across heterogenous application servers and databases? 

Example 

In a given application, a single business process of 
updating a customer record requires an update to a table in 
a UNIX based relational database and then an update to a 
table in a MVS DB2 database. Although there are two 
physical transactions occurring, this entire business process 
is represented as a single logical transaction. Transaction 
Partitioning services allow the application to ensure that the 
individual transactions occurr across the different UNIX and 
MVS systems and that the single logical transaction is 
completed and successful when the individual physical 
transactions are completed and successful. 
ENVIRONMENT 1016,1018 

FIG. 27 illustrates various components of the Environ- 
mental Services of the Netcentric Architecture Framework. 
Environment Services provide miscellaneous application 
and system level services that do not deal directly with 
managing the user-interface, communicating to other 
programs, or accessing data. 
Runtime Services 2702 

Runtime services convert non-compiled computer lan- 
guages into machine code during the execution of a pro- 
gram. 

Language Interpreter 2704 

Language Interpreter Services decompose a 4th genera- 
tion and/or a scripting languages into machine code 
(executable code) at runtime. 
Possible Product Options 
VBRUN300.DLL 

VBRUN300.DLL — runtime Dynamic Link Library that 
supports programs written in Visual Basic. 
Virtual Machine 2706 

Typically, a Virtual Machine is implemented in software 
on top of an operating system, and is used to run applica- 
tions. The Virtual Machine provides a layer of abstraction 
between the applications and the underlying operating sys- 
tem and is often used to support operating system indepen- 
dence. 

Possible Product Options 

Java Virtual Machine; Smalltalk Virtual Machine 

Virtual machines such as the Java virtual machine or the 

Smalltalk virtual machine implement their own versions of 

operating system services in order to provide the application 

with complete platform independence. 

Java virtual machine — software implementation of a 
"CPU" designed to run compiled Java byte code. This 
includes stand-alone Java applications as well as 
"applets" that are downloaded and run in Web brows- 
ers. 

Smalltalk virtual machine — runtime engine that interprets 
application code during execution and supports plat- 
form independence. 
System Services 2708 

Services which applications can use to perform system- 
level functions. These services include: System Security 
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Services, Profile Management Services, Task and Memory 
Management Services, and Environment Verification Ser- 
vices. 

System Security 2710 

5 System Security Services allow applications to interact 
with the operating system *s native security mechanism. The 
basic services include the ability to login, logoff, authenti- 
cate to the operating system, and enforce access control to 
system resources and executables. 

3Q Profile Management 2712 

Profile Management Services are used to access and 
update local or remote system, user, or application profiles. 
User profiles, for example, can be used to store a variety of 
information such as the user's language and color prefer- 
ences to basic job function information which may be used 

15 by Integrated Performance Support or Workflow Services. 
Implementation Considerations 

Is there a need for the application to have its own profile file? 

All MS Windows based application maintain their own 
profile file (XXXXXXXX.INI) that is used during applica- 

20 tion startup, execution, and shutdown. This is a flat text file 
that contains information that can be used by the application 
during various phases of execution. For example, if an 
application needs to connect to a database engine/server, it 
needs to know, during startup, various information like — 

25 database name, the server name, login ID, etc. Instead of 
hard coding all these information in the application 
executable, this information can be stored in the profile file 
for flexibility. In the future, if the database server name 
should change, this change only needs to be entered in the 

30 applications profile file. 

In some cases, it has been seen that this profile informa- 
tion has been hard coded in that applications executable 
itself. This will work, but, it makes the application more 
rigid with no room for any flexibility. 

35 Environment Verification 2714 

Environment Verification Services ensure functionality by 
monitoring, identifying and validating environment integrity 
prior and during program execution, (e.g., free disk space, 
monitor resolution, correct version). These services are 

40 invoked when an application begins processing or when a 
component is called. Applications can use these services to 
verify that the correct versions of required Execution Archi- 
tecture components and other application components are 
available. 

45 Implementation Considerations 

In client/server applications, it may be necessary to imple- 
ment Environment Verification Services to ensure that the 
client and server applications are of a compatible release 
level. 

50 ActiveX framework provides services for automatic 
installation and upgrade of ActiveX controls. When using 
IE, i.e., Microsoft's Web browser, because of its integration 
with Windows OS, ActiveX controls can be automatically 
installed and automatically upgraded on the users machine 

55 without the developer adding any additional code. 
Task and Memory Management 2716 

Task & Memory Management Services allow applications 
and/or other events to control individual computer tasks or 
processes, and manage memory. They provide services for 

60 scheduling, starting, stopping, and restarting both client and 
server tasks (e.g., software agents). 
Implementation Considerations 

Memory management, the allocating and freeing of sys- 
tem resources, is one of the more error prone development 

65 activities when using 3GL development tools. Creating 
architecture services for memory handling functions can 
reduce these hard to debug errors. 
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Java removes, in theory, the problem of memory 
management, by providing a garbage collector; although, its 
implementation is not very efficient in current implementa- 
tions of Java. Future releases of the Java VM promise a 
background-running garbage collector with significantly 
increased performance. 
Application Services 2718 

Application Services are miscellaneous services which 
applications can use for common functions. These common 
functions can apply to one application or can be used across 
applications. They include: Application Security Services, 
Error Handling/Logging Services, State Management 
Services, Help Services, and Other Common Services. 
Application Security 2720 

Besides system level security such as logging into the 
network, there are additional security services associated 
with specific applications. These include: 

User Access Services — set of common functions that limit 
application access to specific users within a company or 
external customers. 
Data Access Services — set of common functions that limit 
access to specific data within an application to specific 
users or user types (e.g., secretary, manager). 
Function Access Services — set of common functions that 
limit access to specific functions within an application 
to specific users or user types (e.g., secretary, manager). 
Implementation Considerations 

In the Netcentric environment, application security 
becomes a more critical component primarily because there 
are more types of users (e.g., employees, customers) and 
additional types of transactions (e.g., e -commerce, help- 
desks). In traditional client/server environments most users 
are employees of the company. In Netcentric environments 
there are typically also external users (e.g., vendors, regis- 
tered users) and the general public. Usually, different types 
of users have different application security requirements 
limiting what data they can see and what functions they can 
execute. Also, new types of transactions such as verifying 
credit when doing e -commerce transactions also require 
additional application security services. 
Error Handling/Logging 2722 

Error Handling Services support the handling of fatal and 
non-fatal hardware and software errors for an application. 
An error handling architecture takes care of presenting the 
user with an understandable explanation of what has hap- 
pened and coordinating with other services to ensure that 
transactions and data are restored to a consistent state. 

Logging Services support the logging of informational, 
error, and warning messages. Logging Services record appli- 
cation and user activities in enough detail to satisfy any audit 
trail requirements or to assist the systems support team in 
recreating the sequence of events that led to an error. 
Implementation Considerations 
Error Handling 

Primarily there are three types of errors: system, archi- 
tecture and application. 
System errors occur when the application is being 
executed and some kind of serious system-level incom- 
patibility is encountered, such as memory/resource 
depletion, database access problems, network problems 
or printer related problems, because of which the 
application cannot proceed with its normal execution. 
Architecture errors are those which occur during the 
normal execution of the application and are generated 
in architecture functions that are built by a project 
architecture team to isolate the developers from com- 
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plex coding, to streamline the development effort by 
re-using common services, etc. These architecture 
functions perform services such as database calls, state 
management, etc. 
5 Application errors are also those which occur during the 
normal execution of the application and are generally 
related to business logic errors such as invalid date, 
invalid price, etc. 
Typically an application is written using a combination of 
jo various programming languages (e.g., Visual Basic and C). 
Therefore, a common error handling routine should be 
written in a language that can be called from any other 
language used in the application. 
Logging 

!5 Logging must be done, however to mitigate problems, 
centralize logs and create a standard, usable log format. 3rd 
party logs should be mapped into the central format before 
any analysis is attempted. 
In a Netcentric environment, errors are rarely logged on 

20 the client machine (one exception may be for an intranet 
type application). 

Logging can add much stress to a Web server and logs can 
grow very large, very quickly, so do not plan to log all 
errors — capture only those which are deemed necessary for 

25 processing exceptions. 
State Management 2724 

State Management Services enable information to be 
passed or shared among windows and/or Web pages and/or 
across programs. So lets say several fields in an application 

30 need to be passed from one window to another. In pseudo- 
conversational mainframe 3270 style applications passing 
data from one screen to another screen was done using 
Context Management Services that provided the ability to 
store information on a host computer (in this paper the term 

35 Context Management refers to storing state information on 
the server, not the client). Client/server architectures sim- 
plified or eliminated the need for Context Management 
(storing state information on the server), and created a need 
to store state information on the client. Typically, in tradi- 

40 tional client/server systems this type of state management 
(i.e., data sharing) is done on the client machine using 
hidden fields, global variables, messages, files or local 
databases. 

The popularity of the Internets HTTP protocol has revived 

45 the potential need for implementing some form of Context 
Management Services (storing state information on the 
server). The HTTP protocol is a stateless protocol. Every 
connection is negotiated from scratch, not just at the page 
level but for every element on the page. The server does not 

50 maintain a session connection with the client nor save any 
information between client exchanges (i.e., web page sub- 
mits or requests). Each HTTP exchange is a completely 
independent event. Therefore, information entered into one 
HTML form must be saved by the associated server appli- 

55 cation somewhere where it can be accessed by subsequent 
programs in a conversation. 

Advances in Netcentric technologies now offer additional 
options for implementing state management on both the 
client and server machines. 

60 Possible Product Options 

NetDynamics Inc. NetDynamics 
NetDynamics Inc. NetDynamics 

NetDynamics provides built-in, developer-definable ses- 
sion and state 25 management. The Persistence Engine 
65 (PE), part of the NetDynamics application server, 
stores all relevant information about a user. Everything 
from the WebID to the exact table row the user is 
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currently viewing can be maintained in the PE. Net- 
Dynamics maintains state information on both the 
server and on the client page. Application state infor- 
mation is maintained by the application server, and 
local state information is maintained on the page. 
NetDynamics provides manipulatable state objects for 
both server and page state information. 
Codes Table Service 2726 

Codes Table Services enable applications to utilize exter- 
nally stored parameters and validation rules. For example, 
an application may be designed to retrieve the tax rate for the 
State of Illinois. When the user enters "Illinois" on the 
screen, the application first validates the user's entry by 
checking for its existence on the "State Tax Table", and then 
retrieves the tax rate for Illinois. Note that codes tables 
provide an additional degree of flexibility. If the tax rates 
changes, the data simply needs to be updated; no application 
logic needs to be modified. 
Implementation Considerations 
Is there a need for the codes table functionality? 

Most applications need code/decode facility. For 
example, an application may need to store codes like — error 
severity codes, etc., stored in a table (may be a cached table) 
instead of in the executable itself. In some cases, where there 
is a small amount of information that needs to be stored in 
the codes table, the profile file (mentioned above) can be 
used instead of the codes table. But in cases where the codes 
table needs to be used quite extensively, then storing the 
code/decode information in the profile file will slow down 
the performance of the application because of the overhead 
of accessing flat files. 

What basic services an architecture should provide in terms 
of managing/using codes/decodes functionality? 

In cases where the application requires extensive use of 
codes table, the architectures Code/Decode component 
should provide the application developers with a set of API 
that can be used to use code/decode tables. This component 
should also provide the option of caching all or parts of the 
codes table in the application machines memory for easier 
and faster access. 

Where should Code/Decode information be stored and 
maintained? 

Code/decode information can be stored at any layer of an 
n-tier architecture — client, application server, or database. 
The decision will need to be based upon codes table size and 
number, information update frequency, and write-access to 
the client machine or device. 
Active Help 2728 

Active Help Services enable an application to provide 
assistance to a user for a specific task or set of tasks. 
Context-sensitive help is most commonly used in applica- 
tions today, however this can imply more "active" support 
that just the Fl key. Typically, today's systems must be 
architected to include Help that is aware of both the user's 
environment, process and context, and in this sense can be 
called "active". Active Help services may include compo- 
nents like Wizards for walking a user through a new process, 
stored or real-time multi-media support, on-demand Com- 
puter Based Training, etc. 
Other Common Services 2726 

Catchall category for additional reusable routines useful 
across a set of applications (e.g., Date Routines, Time Zone 
Conversions, Field Validation Routines). 
Implementation Considerations 
Does the client operate in different date/time zone? 

In most large scale distributed applications, the client and 
the server applications (or machines) are scattered over 
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different time zones. This forces the client applications and 
the server hosts to deal with date and time zone conversions 
(like-CST to PST, etc.) in order to use or display their local 
time accurately. Most of the architectures provide a base set 
5 of APIs that can be used by the applications to convert the 
data/time as needed. 

Does the system requires customized date/time format for 
display purposes? 

Many systems, for certain business reasons, need custom- 

10 ized date and time formats for display and storage purposes. 
In order to do that, the architecture should provide a set of 
APIs that will allow the system to convert data and time 
from one format to the other. 
Does the system deal with high database accesses? 

is As mentioned in the Codes Table Component, sometimes 
it is necessary to cache the data in the memory for faster 
access and less database hits. This a feature that some 
architectures provide as a set of memory management APIs 
to create the cache area in the client platforms memory for 

20 the data to reside. 

Application Integration Interface 2734 

An Application Integration Interface provides a method or 
gateway for passing context and control of information to an 
external application. The Application Integration Interface 

25 specifies how information will be passed and defines the 
interface by which other applications can expect to receive 
information. External applications in this context could 
include anything from Integration Performance Support 
systems to ERP systems like SAP or Peoplesoft to external 

30 custom applications that have been previously developed by 
the client. 

Implementation Considerations 

Where possible, Application Integration Interfaces should 
make use of the Component Model defined by the project to 
35 broker information (i.e. OLE/COM interfaces) as opposed to 
custom building data sharing modules. 
Component Framework 2736 

Component Framework Services provide an infrastruc- 
ture for building components so that they can communicate 
40 within an application and across applications, on the same 
machine or on multiple machines across a network, to work 
together. COM/DCOM and CORBA described in Commu- 
nication Services are the two leading component industry 
standards. These standards define how components should 
45 be built and how they should communicate. 

Object Request Broker (ORB) services, based on COM/ 
DCOM and CORBA, focus on how components communi- 
cate. Component Framework Services, also based on 
CORBA and COM/DCOM, focus on how components 
50 should be built. The currently 2 dominant Component 
Frameworks include: 

1. ActiveX/OLE — ActiveX and Object Linking and 
Embedding (OLE) are implementations of COM/ 
DCOM. ActiveX is a collection of facilities forming a 
55 framework for components to work together and inter- 
act. ActiveX divides the world into two kinds of 
components: controls and containers. Controls are rela- 
tively independent components that present well 
defined interfaces or methods that containers and other 
60 components can call. Containers implement the part of 
the ActiveX protocol that allows for them to host and 
interact with components — forming a kind of back 
plane for controls to be plugged into. ActiveX is a 
scaled-down version of OLE for the Internet. OLE 
65 provides a framework to build applications from com- 
ponent modules and defines the way in which applica- 
tions interact using data transfer, drag-and-drop and 
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scripting. OLE is a set of common services that allow 

components to collaborate intelligently. 

In creating ActiveX from OLE 2.0, Microsoft enhanced 
the framework to address some of the special needs 
of Web style computing. Microsofts Web browser, 
Internet Explorer, is an ActiveX container. 
Therefore, any ActiveX control can be downloaded 
to, and plugged into the browser. This allows for 
executable components to be interleaved with 
HTML content and downloaded as needed by the 
Web browser. 

2. JavaBeans — is Sun Microsystems proposed framework 
for building Java components and containers. The 
intent is to develop an API standard that will allow 
components developed in Java (or beans), to be embed- 
ded in competing container frameworks including 
ActiveX or OpenDoc. The JavaBeans API will make it 
easier to create reusable components in the Java lan- 
guage. 

Other component frameworks include: 

OpenDoc — CI Labs was formed in 1993 and created the 
OpenDoc architecture to provide a cross-platform alter- 
native component framework — independent of 
Microsofts OLE. The OpenDoc architecture is con- 
structed from various technologies supplied by its 
founding members — IBM, Apple and Word Perfect. 
The technologies include: Bento (Apples object storage 
model), Open Scripting Architecture (OSA — Apples 
scripting architecture) and SOM/DSOM (IBMs System 
Object Model/Distributed SOM). IBMs SOM architec- 
ture provides analogous services to that of Microsofts 
DCOM architecture. 

OpenDoc provides an open compound document infra- 
structure based on CORBA. It uses CORBA as its 
object model for inter-component communications. 
OpenDoc architecture provides services analogous 
to those provided by OLE and OpenDoc components 
can also inter-operate with OLE components. The 
OpenDoc equivalent of an object is termed a part. 
Each type of part has its own editor and the OpenDoc 
architecture has responsibility for handling the com- 
munications between the distinct parts. 
Supporters claim OpenDoc provides a simpler, more 
technically elegant solution for creating and manipu- 
lating components than does OLE. The drawback is 
that OpenDoc is not yet commercially proven, like 
OLE. Ironically, one of the more popular uses of 
OpenDoc tools is for creating and implementing 
OLE clients and servers. Because OpenDoc provides 
a more manageable set of APIs than OLE, it may be 
that OpenDoc gains initial acceptance as an enabler 
of OLE applications before becoming recognized as 
a complete component software solution itself. 
ONE — Open Network Environment (ONE) is an object- 
oriented software framework from Netscape Commu- 
nications for use with Internet clients and servers, 
which enables the integrating of Web clients and serv- 
ers with other enterprise resources and data. By sup- 
porting CORBA, ONE-enabled systems will be able to 
link with object software from a wide array of vendors, 
including IBM, Sun Microsystems, Digital Equipment, 
and Hewlett-Packard. Netscape is positioning ONE as 
an alternative to Microsoft's Distributed Common 
Object Model (DCOM). ONE also complies with Sun 
Microsystems Java technology. 
Implementation Considerations 

An architecture that utilizes components brings many of 
the benefits of object orientation to applications. 
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Component-based or document-centric applications are 
composed of intelligent components, each of which contains 
logic, possibly data and a set of well defined interfaces or 
APIs to the services they provide (e.g., a customer compo- 
nent or an Excel chart component). The similarities to object 
oriented are more than just coincidental. Component soft- 
ware is viewed by many as a more viable object approach 
focusing on larger grain of modularity and reuse. 

Two important issues driving the decision around what 
should be a component are software re-use and software 
packaging. Software re-use will primarily stem from defin- 
ing components at a level at which they can be re-used 
within the same application and across many applications. 
Although re-usable components can be at any level, more 
often they will probably be at an object level where they are 
more granular. Software packaging will be driven by defin- 
ing components at a level at which they can be distributed 
efficiently to all users when business logic changes occur. If 
the application is large, perhaps it is better to package the 
application by breaking it up into process components such 
as customer maintenance, sales order maintenance, etc. So 
when a change to one of the processes occurs, only the 
component which contains that process needs to be distrib- 
uted to client machines, rather than the whole application. 
For example, a developer can create an ActiveX control that 
will encapsulate the Employee Maintenance Process, which 
includes adding new employees, updating and deleting 
existing employees. This ActiveX control can be a part of an 
overall human resource intranet application. When the func- 
tionality within the Employee Maintenance Process 
changes, the next time the user accesses the human resource 
application from the Web browser, ActiveX technology will 
automatically download the latest version of the ActiveX 
control containing the most recent update of the Employee 
Maintenance Process to the client machine, if the client 
machine does not have the latest version. 
Component architectures typically employ of a three-tier 
component architecture utilizing the following three types of 
components: 

User Interface, Process, and Domain. While these three 
component types may go by different names on different 
projects, they all follow the same basic pattern and are 
briefly explained below: 

User Interface components typically contain nothing 
more than the logic required to manipulate input and 
output to the user. This can include input validation 
requiring no additional server data, as well as simple 
calculations associated with field display. In addition, 
logic associated with dynamically changing the display 
(e.g., a checkbox entry causes a field to become 
disabled) is placed here. 
Process components typically contain the logic associated 
with business transactions performed on data. This is 
often the point where transaction commit/rollback 
occurs. These components are typically invoked by the 
User Interface components. 
Domain components typically contain the logic associ- 
ated with accessing and maintaining business entities, 
i.e., data. These components are usually invoked by 
Process components when requiring access to or 
manipulation of data. However, in addition to data 
access, these components may often be used to perform 
manipulations involving the processing of data within 
the domain of that component. For example, a Cus- 
tomer Domain component might be requested to deter- 
mine if it's credit limit had been exceeded when 
provided with a new invoice amount. 
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Build vs. Buy 

There is an explosion of components available in the 
market place and the ease of accessing and down loading 
components from the Internet; the decision to buy or build 
a component is as real as ever. In general clients expect more 5 
justification of a build decision v. a buy decision. Feel out 
the client and the expectations and requirements they may 
have. 

Components are a viable option and should be researched, 
even includingeven simple UI controls available on the 10 
Internet. Look at market trends to determine which 
applications/components can meet the bulk of the system 
needs. 

Operating System 2738 

Operating System Services are the underlying services 15 
such as multi-tasking, paging, memory allocation, etc., 
typically provided by todays modern operating systems. 
Where necessary, an additional layer or APIs may be pro- 
vided to gain either operating system independence or a 
higher level of abstraction for application programmers. 20 
Possible Product Options 

Microsoft Windows; Windows 95; Windows NT; Macintosh 
OS; OS/2; Unix and Java OS 
Base Services 1020 

Component Description 25 

FIG. 28 illustrates the Base Services of the Netcentric 
Architecture Framework. Base Services provide server- 
based support for delivering applications to a wide variety of 
users over the Internet, intranet, and extranet. The informa- 
tion about these services in the Netcentric framework may 30 
be limited based on the least common denominator. For 
more detailed information about these components refer also 
to the following frameworks in SAF and/or DAF. 
Batch Delivery Vehicle 

Collaboration Framework for Structured Information 35 
(Workflow) 
Web Services (2820) 

Web Server Services enable organizations to manage and 
publish information and deploy Netcentric applications over 
the Internet and intranet environments. These services sup- 40 
port the following: 

Managing documents in most formats such as HTML, 
Microsoft Word, etc. 

Handling of client requests for HTML pages. A Web 45 
browser initiates an HTTP request to the Web server 
either specifying the HTML document to send back to 
the browser or the server program (e.g., CGI, ASP) to 
execute. If the server program is specified, the Web 
server executes the program which generally returns a 50 
formatted HTML page to the Web Server. The Web 
server then passes this HTML page just as it would any 
standard HTML document back to the Web browser. 

Processing scripts such as Common Gateway Interface 
(CGI), Active Server Pages (ASP). Server side script- 55 
ing enables programs or commands to be executed on 
the server machine providing access to resources stored 
both inside and outside of the Web server environment. 
For example, server side scripts can be used to process 
requests for additional information, such as data from $0 
an RDBMS. 

Caching Web pages. The first time a user requests a Web 
page, the Web server retrieves that page from the 
network and stores it temporarily in a cache (memory 
on the Web server). When another page or the same 65 
page is requested, the Web server first checks to see if 
the page is available in the cache. If the page is 



available, then the Web server retrieves it from the 
cache, otherwise it retrieves it from the network. 
Clearly, the Web server can retrieve the page from the 
cache more quickly than retrieving the page again from 
its location out on the network. The Web server typi- 
cally provides an option to verify whether the page has 
been updated since the time it was placed in the cache, 
and if it has to get the latest update. 
Possible Product Options 

Netscape Enterprise Web Server; Microsoft Internet Infor- 
mation Server (IIS); Oracle Webserver 

The following are relevant products for providing or 
implementing HTTP Web Server Services: 
Netscape Enterprise Web Server 

An enterprise-strength Web server that enables organi- 
zations to manage and publish their information and 
deploy Netcentric applications. Netscape Enterprise 
Web Server is built on open Internet standards that 
enable information and applications to scale easily. 
Supports S-HTTP, Java, and SNMP. 
Microsoft Internet Information Server (IIS) 
A free add-on product for NT Server that implements 
basic HTTP services. Future versions of NT Server 
(4.0 and beyond) will have HTTP features built 
directly into the operating system. 
Oracle Webserver 

A multi -threaded HTTP server that provides integrated 
features for translating and dispatching client HTTP 
requests directly to the Oracle7 Server using 
PL/SQL. 
Push Pull Services (2840) 

Push/Pull Services allow for interest in a particular piece 
of information to be registered and then changes or new 
information to be communicated to the subscriber list. 
Traditional Internet users "surf" the Web by actively moving 
from one Web page to another, manually searching for 
content they want and "pulling" it back to the desktop via a 
graphical browser. But in the push model, on which sub- 
scription servers are based on, content providers can broad- 
cast their information directly to individual users' desktops. 
The technology uses the Internet's strengths as a two-way 
conduit by allowing people to specify the type of content 
they want to receive. Content providers then seek to package 
the requested information for automatic distribution to the 
user's PC. 

Depending upon requirements, synchronous or asynchro- 
nous push/pull services may be required. Synchronous push/ 
pull services provide a mechanism for applications to be 
notified in real time if a subscribed item changes (e.g., a 
stock ticker). Asynchronous push/pull services do not 
require that a session- like connection be present between the 
subscriber and the information. Internet ListServers are a 
simple example. Subscribers use e-mail to register an inter- 
est in a topic and are notified via e-mail when changes-occur 
or relevant information is available. Asynchronous push/pull 
services can be useful for pro-actively updating customers 
on changes in order status or delivering information on new 
products or services they have expressed an interest in. 

PointCast; Marimba; IBM/Lotus; Microsoft; Netscape; 
America Online; BackWeb; Wayfarer 

Castanet from Marimba — distributes and maintains soft- 
ware applications and content within an organization or 
across the Internet, ensuring subscribers always have 
the most up-to-date information automatically. 

PointCast — news network that appears instantly on the 
subscribers computer screen. 
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Batch Services (B2060) 

Batch processing is used to perform large scale repetitive 
processing where no user involvement is required as well as 
reporting. Areas for design attention include scheduling, 
recovery/restart, use of job streams and high availability 
(e.g. 24 hour running). In addition close attention must be 
paid to performance as batch systems usually must be 
processed within strict batch windows. 

The design of batch architectures is often complicated 
considerably by the fact that batch jobs must be able to run 
concurrently with on-line systems. The general globalization 
of companies requires that he on-line systems must be 
available on a close to 24x7 hours basis, eliminating the 
traditional batch windows. Concurrent batch and on-line 
processing poses serious challenges to data integrity, 
throughput and performance. 

Batch application programs can include business process- 
ing such payroll, billing, etc. and can also include report 
generation. This is an often overlooked area in client/server 
architectures. Traditional client/server solutions and Netcen- 
tric solutions often require batch processing, but unlike the 
mainframe, the typical platforms and development environ- 
ments used often do not have built-in batch or reporting 
architecture facilities. 

Batch processing should be used in preference to on-line 
modules when: 

The same process, or set of processes, must be applied to 
many data entities in a repetitive and predictable fash- 
ion. 

There is either no manual element to the process or the 
manual element can be completely separated from a 
batch element. 
The volume of information to be presented to a user is too 
great to be processed on-line or it can be better printed 
in batch. 
Related Patterns 

For more detailed information about component based 
batch design patterns, refer also to the Batch patterns in the 
Patterns section: 

Base Services Patterns Overview 
Abstraction Factory 
Batch Job 

BUW— Batch Unit of Work 
Processing Pipeline 
Is Report Services (2880) 

Report Services are facilities for simplifying the construc- 
tion and delivery of reports or generated correspondence. 
These services help to define reports and to electronically 
route reports to allow for online review, printing, and/or 
archiving. Report Services also support the merging of 
application data with pre-defined templates to create letters 
or other printed correspondence. Report Services include: 
Driver Services. These services provide the control struc- 
ture and framework for the reporting system. 
Report Definition Services. These services receive and 
identify the report request, perform required validation 
routines, and format the outputted report(s). After the 
request is validated, the report build function is initi- 
ated. 

Report Build Services. These services are responsible for 
collecting, processing, formatting, and writing report 
information (for example, data, graphics, text). 

Report Distribution Services. These services are respon- 
sible for printing, or otherwise distributing, the reports 
to users. 
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Functions and Features of a Report Architecture 

The report architecture within Environment Services sup- 
ports the generation and delivery of reports. Applications 
request report services by sending a message to the reporting 
framework. 

The following types of reports are supported by the 
reporting application framework: 

Scheduled: Scheduled reports are generated based upon a 
time and/or date requirement. These reports typically 
contain statistical information and are generated peri- 
odically (invoices and bills, for example). 

On-demand: Some reports will be requested by users with 
specific parameters. The scheduling of these reports, 
the formatting, and/or the data requirements are not 
known before the request is made, so these factors must 
be handled at request time. 

Event -driven: This report type includes reports whose 
generation is triggered based on a business or system 
event. An example here would be a printed trade slip. 

Reporting Application Framework 

FIG. 29 shows the major components of the reporting 
application framework: 
Report Initiation (2900) 

The report initiation function is the interface for reporting 
applications into the report architecture. The client initiates 
a report request to the report architecture by sending a 
message to the report initiation function. The responsibility 
of report initiation is to receive, identify, and validate the 
request and then trigger the report build process. The main 
components of reporting initiation are the following. 
Receive, identify, and validate a report request. The 
identification function determines general information 
about the request, such as report type, requester, quan- 
tity to be printed, and requested time. Based on the 
report type, a table of reports is examined in order to 
gather additional report-specific information and per- 
form required validation routines for the report request. 
After the report identification and validation functions 
have been successfully completed, the reporting pro- 
cess can continue. If any errors are identified, the report 
initiation function will return an error message to the 
requester application. 
Initiate report execution. The initiate report execution 
function processes the report profile and specific dis- 
tribution requirements and determines the report to be 
created. It then passes control to the report execution 
process. 
Report Execution (2902) 

Report execution is the core of the reporting application 
framework. The main components of report execution 
include: 

Format the report. This function is responsible for for- 
matting the layout of the outputted report, including 
standard headers, column headings, row headings, and 
other static report information. 

Collect the information. This function is responsible for 
collecting the information (for example, data, text, 
image, graphics) that is required for the report. This 
function would utilize the Information Access Services 
component of the client/server architecture. 

Format the information. This function is responsible for 
formatting the collected information into the appropri- 
ate display format based upon the report type and the 
report distribution requirements. 
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Output the report. This function initiates the report dis- 
tribution function in order to distribute the created 
report to the specified devices (printers, disks, and so 
forth) and individuals. 

The process of collecting, processing, formatting, and 
outputting report data can be accomplished in several dif- 
ferent ways. For example, one method is to create a program 
in C for each report format. Here, many aspects of report 
printing — such as page size, headings, footings, and printer 
control values — would have to be programmed in function 
calls to facilitate the report programming process. Informa- 
tion access to files or the database would be through Infor- 
mation Access Services. 

Another option is to use a third-party report tool, such as 
the SQR (Structured Query Report Writer) from SQL Solu- 
tions. SQR is a robust report generator designed to be used 
with SQL-based relational databases. SQR insulates the 
developer from programming in a third generation language 
by providing a higher-level programming language. SQL 
queries (Information Access) are placed directly into the 
SQR program. 
Report Distribution (2904) 

The final requirement of the reporting application frame- 
work is the report distribution function. Once the report has 
been generated, it must be distributed to the specified targets 
(devices and/or users). The report distribution function will 
locate completed report files and route them to the appro- 
priate devices within the client/server network. 

Typically, a report distribution database is used to specify 
the destinations for each report supported by the report 
architecture. The report distribution database specifies 
where, when, how, and to whom to distribute the produced 
report. Specific destinations can include: printers), user(s), 
user groups, archives (permanent storage), and/or specific 
display devices such as workstations and terminals. 

Several additional options exist for distributing reports 
including timed reporting, multiple copy distribution, and 
report archiving. Also, a user interface function can be built 
to open and browse report files. 

Custom Reporting Approaches 

If a commercially- available reporting product can not 
meet your report requirements, you may have to consider a 
custom approach. FIG. 30 illustrates an example of how a 
custom report architecture relates to a workstation platform 
technology architecture. 

This custom report process is responsible for processing 
all messages requesting generation, manipulation, or distri- 
bution of reports. The following services are provided in an 
environment including a pair of workstations 3000 and a 
server 3002: 

Report generation 

Report deletion 

Report printing 

Report status maintenance 

Report generation is supported by an additional report 
writer process that contains all application-defined report 
writer modules. These modules contain the logic to produce 
each of the report types that may be requested. The report 
process receives generation requests and ensures that they 
are forwarded to the report writer process at the current or 
specified time. All report requests are processed in an 
asynchronous manner (for example, service requesters do 
not wait for completion of report processing). 

FIG. 31 describes the relationships between the major 
components of the report process 3100 and the report writer 
process 3102. 
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Design Approach 

For the report process in a client/server system, a set of 
APIs is provided for use within application programs and 
within the application report writer modules. Each API 
5 requests a specific report service (generation, printing, or 
deletion) which is performed by a report manager module. 

The report process maintains an internal database table, a 
report status table, containing information about each report 
that has been requested for generation, including: 
10 Requester ID 

Report name 

Date/time requested 

Status (requested, in process, complete, or error) 
15 Report-specific parameters. 

The requester ID, report name, and date/time are used to 
uniquely identify the is report. These values are passed to 
APIs which request report status, print or delete a previously 
generated report, 
20 All application-defined report writer modules invoke an 
API to update the report status table with a status of 
"completed 1 ' after a report has been produced or with "error" 
if the report cannot be generated. An API is also provided to 
print the report after the generation if specified in the 
25 original request. 

Processed report records are removed from the table only 
after the output reports have been archived. Implementation 
and frequency of this table cleanup is to be determined in 
systems management design. 
30 Report Process Flows 

Report processing is message-driven. Each defined API 
sends a unique message to the report process. The report 
process reads the messages from a queue and invokes the 
appropriate modules to handle each request. Subsequent 
35 process flows differ based upon the requested service. In the 
case of a report generation request, the process flow pro- 
ceeds as follows: 

A record is added to the report status table. 
A message is sent to the report writer process for imme- 
40 diate generation or to the event manager for generation 
at a specified time (report scheduling). 
The appropriate application report writer module gener- 
ates the report, prints it if specified in the original API 
request, and updates the status in the report status table. 
45 A request to print a report proceeds as follows: 

The report status is retrieved from the report status table. 
The output file is located on disk and sent to the specified 
or default printer or the request is sent to the event 
manager for report scheduling. 
50 Report deletion proceeds as follows: 

The report record is removed from the report status table. 
The report file is removed from disk. 
Status information requests are performed directly from 
55 the API using Information Access Services APIs. No inter- 
action with the report process is necessary, which results in 
improved performance. 
Modules 

FIG. 32 shows the module hierarchy for the custom report 
60 process. The Figure shows the relationships between 
modules, not their associated processing flows. It should be 
used to identify the calling module and the called modules 
for the process. FIG. 32 illustrates the Architecture Manager 
library 3200 which supports the report process. 
65 The functions designed to support this process are: 
Generate Report 
Get Report Status 
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Control Reports 
Request Report (b2402) 
Delete Report (b2406) 
Print Report (b2404) 

Generate Report. This module is called to request report 
generation and printing (optional). Input data blocks specify 
the following: 

Report name 

Report parameters 

Report generation time (default is immediately) 
Printer name. 

The report name must be one of the defined application 
report types. Valid report parameters vary depending on the 
report type. Reports may be requested for generation imme- 
diately or at a designated future time. All reports are written 
to a reserved area on disk; however, specification of a printer 
causes the output to be printed as well as stored on the file 
system. 

Get Report Status. The Get Report Status function 
retrieves status information about all reports that have been 
previously requested for generation by the calling process. 
Returned is a list containing the requested data as well as the 
number of reports found. 

Control Reports. The Control Reports function is respon- 
sible for performing various operations on reports. The 
following services are provided: 

Delete a report request and any associated output 

Print a previously generated report. 

Update report status. 

In all cases, the report name is passed through an input 
data block. For the print service, a printer name is passed. 
For status update, the new status code is passed. 

Request Report. The Request Report function is respon- 
sible for processing report request messages written to the 
report process queue. It creates a new entry in the report 
status table with a status of "requested" and initiates the 
report writer process for immediate generation or sends a 
message to the event manager for future report, generation. 

Delete Report. The Delete Report function is responsible 
for removing a report from the Report Status list and 
deleting the generated output file (if any). 

Print Report. The Print Report fuinction sends a generated 
report output file to a specified or default printer. The report 
name and requesting process ID is passed to identify the 
report. 

Evaluation Criteria 

There are two primary approaches to implementing a 
reporting architecture: custom and package. Evaluating cus- 
tom and package solutions involves both functional and 
technical criteria. The following is a discussion of various 
functional and technical criteria that should be considered 
during the planning for a report architecture. Note that not 
all of the criteria may be required by any particular organi- 
zation. 

Functional Criteria 

1. Report Repository: The report architecture should work 
with, and support maintenance of, a report repository on the 
platforms within the client/server architecture. The report 
repository contains the detailed definitions of the reports. 

2. Workgroup Report Support: The report architecture 
should work with and support distribution of reports gener- 
ated on the workgroup server. 

3. On-Demand Reports: The report architecture must 
support distribution of reports requested by users on 
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demand. Typically, these reports will not have a set schedule 
or frequency for distribution. The report architecture must 
support distribution of these reports without the requirement 
of manual or user intervention (subsequent to initial set up 
5 and conversion). 

4. Scheduled Reports: The report architecture must sup- 
port distribution of regularly scheduled reports. Typically, 
these reports will have a set schedule and frequency for 
distribution. The report distribution package must support 

1(J distribution of these reports without the requirement of 
manual or user intervention (subsequent to set up and 
conversion). 

5. Online Preview: The report architecture should allow 
preview of reports online from a user's intelligent worksta- 
tion prior to actual distribution. Ideally, the report architec- 

15 ture itself would provide support for online preview of 
reports through software located on the intelligent worksta- 
tion. 

6. Graphical User Interface: The architecture should pro- 
vide users with a graphical user interface. 

20 7. Bilingual Support: For companies where two or more 
languages are used, the report architecture must provide a 
multi-national user interface. (Note that large report runs 
targeted for multiple users may require the ability to change 
languages during the report.) 
25 8. Basic Preview Functions: The report architecture 
should support basic preview functions. These include: 
Scrolling up and down. 
Scrolling left and right. 
30 Advancing to end or beginning of report without scrolling 
through intermediate pages. 

9. Advanced Preview Functions: In addition to the basic 
preview functions listed previously, certain advanced pre- 
view functions may also be necessary: 

35 Page indexing (allows users to jump to specific report 
pages). 

Section indexing (allows users to jump to specific report 
sections). 

Search capabilities (allows users to search report for 
40 occurrence of a specific data stream). 

10. Report Level Security: Reports may occasionally 
contain sensitive information. It is therefore important that 
access to certain reports be restricted to authorized users. 
The report architecture should provide a mechanism for 

45 implementing report level security. This security must be in 
place on all platforms with the client/server architecture. At 
the workgroup level, the security may consist of download- 
ing sensitive report files to a secure directory, and having the 
LAN administrator release the report as appropriate. 

50 11. Section, Page, and Field Level Security: Defining 
security at the report section, page, or field level would 
provide greater flexibility in determining and implementing 
report security. This is a desirable, though not mandatory, 
requirement of the report architecture. 

55 12, Background Processing: The report architecture 
should support the processing of reports in the background 
while the application works in the foreground during online 
hours. In other words, processing of reports should not 
negatively affect online response times, or tie up the user's 

60 workstation. 

13. Automatic Report Addressing: The report architecture 
should provide a "humanly intelligible" address for all 
distributed reports. The address may be used by a print site 
operator, LAN administrator, or other personnel to manually 

65 sort printed output (if required). This criterion can be 
satisfied by automatic creation of banner pages or other 
means. 
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14. Delivery Costing: To provide sufficient information to 
users to avoid accidentally downloading or printing very 
large reports during peak usage hours, a distribution costing 
function can be useful. This function would warn users of 
reports that would overload the network or a printer This 5 
costing function might provide recipients with a rough 
estimate of the amount of time that distribution might take. 
Finally, during the online day, the delivery costing mecha- 
nism might disallow transmission of reports that exceed a 
predetermined cost. 1Q 

15. Multiple Destinations: The report architecture should 
support distribution of a single report to single or multiple 
destinations. 

16. Destination Rationalization: For some systems, it is 
possible that multiple copies of a report will be sent to the 
same site — to several different users, for example. In these 15 
cases, it is highly desirable to have the report architecture 
recognize these situations whenever possible and distribute 
the specified report only once. 

17. Automatic Printing: The report architecture should 
provide automatic print capabilities. Once a report has been 20 
distributed for printing (either through a "push" distribution 
scheduling mechanism or through a "pull" user request) no 
further user or operations personnel involvement should be 
necessary to print the report at the specified location. 

18. Multiple Print Destinations: The report architecture 25 
should support distribution of reports for printing at 
centralized, remote, or local print sites without user or 
operations personnel intervention. 

19. Variable Printer Types: Printing on multiple types of 
printers, including line, impact, and laser printers, should be 3Q 
supported. This should not require user intervention — that 

is, the user should not have to specify the type of target 
printer. Ideally, the report architecture would default this 
information from the user's profile or the default printer 
defined in the local operating system. This criterion requires 
that the report architecture support several print 35 
mechanisms, such as postscript drivers and host/mainframe 
protocols (for example, Advanced Function Printing [AFP]). 

20. Variable Printer Destinations: The report architecture 
should default the destination printer for a specific report 
(from the user's profile or operating system parameters). 40 
Additionally, the architecture should allow the user to 
change the printer specified. Validation of the print destina- 
tion also should be included. 

21. Special Forms Printing: The report architecture should 
support distribution of "regular" reports and special forms 45 
reports. 

22. Font Support: Some reports may be printed on laser 
printers and/or may support electronic forms text (i.e., 
including the forms text in the report dataset as opposed to 
printing the report dataset on a pre-printed form). The 50 
architecture should allow multiple fonts to be specified. 

23. Report Archival: The report architecture should pro- 
vide and/or facilitate archival or disposition of report 
datasets. Ideally, the architecture would permit definition of 
retention periods and disposition requirements. 55 

24. Report Download: The report architecture should 
allow distribution of the information contained in a report 
dataset to a user's intelligent workstation. The information 
should be in a form that can be imported to a local word 
processing software, decision support software package, or 60 
other appropriate application. 

25. Application Transparency: It is desirable for the report 
architecture to appear to the users as if it were part of the 
overall application. This does not necessarily mean that the 
architecture must integrate seamlessly with the application; 65 
a message interface between the systems might be accept- 
able. 
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26. Selective Printing: It would be desirable for the report 
architecture to provide users with the ability to print only 
selected pages or sections of the report. This should reduce 
paper usage, while still allowing users to obtain a hard copy 
of the information as required. 

27. Print Job Restart: It would be desirable if the report 
architecture allowed a print job to be restarted from the point 
of failure rather than having to reprint the entire report. This 
of particular concern for very large reports. 

Technical Criteria 

The following is a list of technical criteria that should be 
considered during the planning for a report architecture: 

1. Platform Compatibility: The report architecture must 
be compatible with the platform architecture. It also should 
be compatible with local area networks and standalone 
workstation technology specified in the platform architec- 
ture. 

2. Wide Area Network Compatibility: Most systems will 
include support for WAN communication, so the report 
architecture should be compatible with this environment. 

3. Technology Standards: The report architecture should 
be compliant with existing formal and de facto standards 
(for example, SQL Database Language, COBOL Program- 
ming Language, C Programming Language). 

4. External User Directory: The report architecture should 
make use of an external user directory of preferences and 
locations. 

5. Data Compression in Report Repository: To reduce the 
storage requirements for the report repository, it is also 
desirable for the report architecture to support data com- 
pression in the repository. 

6. Code Page Compatibility: Code page compatibility 
must be considered when translating characters to ASCII. 
Workflow Services (2890) 

Workflow services control and coordinate the tasks that 
must be completed in order to process a business event. For 
example, at XYZ Savings and Loan, in order to receive a 
promotion, you must complete an essay explaining why you 
should be promoted. This essay and your personnel file must 
be routed to numerous individuals who must review the 
material and approve your promotion. Workflow services 
coordinate the collection and routing of your essay and your 
personnel file. 

Workflow enables tasks within a business process to be 
passed among the appropriate participants, in the correct 
sequence, and facilitates their completion within set times 
and budgets. Task definition includes the actions required as 
well as work folders containing forms, documents, images 
and transactions. It uses business process rules, routing 
information, role definitions and queues. Workflow func- 
tionality is crucial for the customer service and engineering 
applications to automate the business value chains, and 
monitor and control the sequence of work electronically. 

The business processes can be of a repetitive nature, eg 
automatically routing and controlling the review of a work 
plan through the approval stages. These are called produc- 
tion workflows. Conversely it can be an ad hoc process, eg 
generating and delivering a work order for a special meter 
reading to a meter reader who is available to perform the 
task. In production workflows the processes are predefined, 
whereas ad hoc workflows are created only for a specific 
nonrecurrent situation. Often it is difficult to determine how 
much ad hoc functionality that needs to be provided. An 
overly strict production workflow may not support necessary 
special cases that must be handled in an ad hoc fasion. 

Workflow provides a mechanism to define, monitor and 
control the sequence of work electronically. These services 
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are typically provided by the server as they often coordinate 
activities between multiple users on multiple computers. 

The following are some of the architectural and integra- 
tion issues that must be addressed: 
Process integration 
The workflow system must achieve a seamless integra- 
tion of multiple processes. The workflow system 
must control the business process, eg it should be 
able to open a word processor with the relevant data 
coming from a previous business process; 
Infrastructure integration from PC to mainframe 

The ability to interface with the host-based hardware, 
system software, and database management systems 
is critical. This is essential because the workflow 
system is located between the client-based and host- 
based processes, ie it can initiate client-based as well 
as host-based applications; 
LAN and WAN connectivity 

Connectivity must include all sites for the supported 
processes, enabling a large number and variety of 
users to use the workflow system, and thus to execute 
the business process; 
Integration of peripherals 
The workflow system should support many different 
types of printers, modems, fax machines, scanners, 
and pagers. This is especially important because of 
the diversity of the users that will be involved, from 
field crew to managers, each with their own needs 
and preferences; and 
Integration with workflow-participating applications 
The key to the efficiency of the workflow system is its 
capability to integrate with office automation, 
imaging, electronic mail, and legacy applications. 
Workflow can be further divided into the following com- 
ponents: 

Role management 

Role management ie provides for the assignment of 
tasks to roles which can then be mapped to individu- 
als. 

A role defines responsibilities which are required in 
completing a business process. A business worker 
must be able to route documents and folders to a role, 
independent of the specific person, or process filling 
that role. For example, a request is routed to a 
supervisor role or to Purchasing, rather than to 
"Mary" or "Tom." If objects are routed to Mary and 
Mary leaves the company or is reassigned, a new 
recipient under a new condition would have to be 
added to an old event. Roles are also important when 
a number of different people have the authority to do 
the same work, such as claims adjusters; just assign 
the request to the next available person. In addition, 
a process or agent can assume a role; it doesn't- need 
to be a person. Role Management Services provide 
this additional level of directory indirection. 
Route management 

Route management enables the routing of tasks to the 
next role, which can be done in the following ways: 
Serial — the tasks are sequentially performed; 
Parallel — the work is divided among different play- 
ers; 

Conditional — routing is based upon certain condi- 
tions; and 

Ad hoc — work which is not part of a predefined 
process. 

Workflow routing services route "work" to the appro- 
priate workflow queues. When an application com- 
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pletes processing a task, it uses these services to 
route the work-in-progress to the next required task 
or tasks and, in some cases, notify interested parties 
of the resulting work queue changes. 

The automatic movement of information and control 
from one workflow step to another requires work 
profiles that describe the task relationships for com- 
pleting various business processes. The concept of 
Integrated Performance Support can be exhibited by 
providing user access to these work profiles. Such 
access can be solely informational — to allow the user 
to understand the relationship between tasks, or 
identify which tasks need to be completed for a 
particular work flow — or navigational — to allow the 
user to move between tasks. 

Route Management Services also support the routing 
and delivery of necessary information (e.g., 
documents, data, forms, applications, etc.) to the 
next step in the work flow as needed. 
Rule Management 

A business process workflow is typically composed of 
many different roles and routes. Decisions must be 
made as to what to route to which role, and when. 
Rule Management Services support the routing of 
workflow activities by providing the intelligence 
necessary to determine which routes are appropriate 
given the state of a given process and knowledge of 
the organization's workflow processing rules. Rule 
Management Services are typically implemented 
through easily maintainable tables or rule bases 
which define the possible flows for a business event. 
Queue Management 

These services provide access to the workflow queues 
which are used to schedule work. In order to perform 
workload analysis or to create "to do lists" for users, an 
application may query these queues based on various 
criteria (a business event, status, assigned user, etc.). In 
addition, manipulation services are provided to allow 
queue entries to be modified. 
Workflow services allow users and management to moni- 
tor and access workflow queue information and to 
invoke applications directly. 
Is there a need for reporting and management facilities? 

Typical workflow application requirements are better gen- 
eral management control and better management of change. 
Proactive system action, audit trails and system administra- 
tion features like work queue reporting are important admin- 
istration tools. Some of the areas for monitoring for 
improvement are employee productivity, process 
performance, and forecasting/scheduling. Where any form 
of customer service is involved, features like status reports 
on individual cases can sharpen customer response times 
while performance monitoring of groups and individuals can 
help quality improvement and efficiency exercises. Note that 
reports and reporting does not necessarily mean paper 
reports that are distributed in a traditional manner, it can 
mean electronic messages or even triggers based on specific 
events. 

Are cooperative applications present? 

Workflow management is frequently required in coopera- 
tive applications because the users are generally 
professionals, the flow of work in the organization is fre- 
quently highly variable, the application units of work (legal 
case, sales order) are processed for long periods of elapsed 
lime, and work often moves from one processing site to 
another. As data and application logic are split, better control 
is needed to track processing/data status across location. 
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Will there be business process re-engineering? 

Workflow is a logical complement to BPR and the trend 
is moving toward using workflow software to re-engineer 
new business processes on a workgroup or project basis. 
Is the business process well defined? 5 

If rules or conditions can be identified which define the 
business process, with few exception conditions, workflow 
tools can then automate areas such as information routing, 
task processing, and work-in-process reporting. 
Are fixed delays or deadlines involved? 

Workflow has been used to regulate delays and deadlines 
such as those associated with government regulations, con- 
tractual obligations, accounting periods, customer service, 
and sales lead follow-up. Typical workflow goals are shorter 
time to market and quicker response times. 
Are multiple people involved in the business process? 15 

Workflow co-ordinates cross-functional, cross- 
departmental work activities and promotes accountability. It 
also enables dynamic redistribution and reprioritization of 
work. 

Is there a need for work scheduling? 20 

Workflow management can be extended to automate work 
scheduling. A system may be able to do as good a job, or 
better, in scheduling a users work. This might be due to a 
very large amount of work to be assigned to a large pool, a 
complex method of assigning priorities, an extremely 25 
dynamic environment, or some other reason. Another advan- 
tage to work scheduling is that the system can initiate some 
needed activity automatically for the user in anticipation of 
the next task. 

Do integration issues exist? 30 

It is important to determine how well the workflow 
system integrates with host-based hardware, system 
software, database management systems, and communica- 
tion networks. Examples of items to consider include 
E-mail, database, GUI tool, PC applications, other office 35 
systems, and business applications. 
How scaleable is the product? 

Number of workers the product could reliably support in 
a production environment. Two major product factors char- 
acterize seal ability:, (1) Platform alternatives (hardware and 40 
operating system); and (2) Message-based architecture 
(relying on specific mail systems for much of the 
functionality) versus Database-based. 
What is the nature of the workflow? 

How an organization approaches the management of its 45 
workflow will determine which workflow management tools 
are appropriate to the organization. In general, there are 
three types of workflow, production, collaborative, and ad 
hoc. A production environment involves high transaction 
rates and thousands of documents in which the rules for a 50 
certain document can be defined for most of the time. 
Examples include accounts payable, insurance claims 
processing, and loan processing. A collaborative environ- 
ment involves multiple departments viewing a single docu- 
ment with typically less number of documents than in the 55 
production environment. One example is a sales order. Ad 
hoc workflows arise from the specific temporary needs of a 
project team whose members become active and inactive 
depending on their function within the group. 
What is the relationship between the workflow and imaging 60 
components? 

It may be important to determine whether or not the 
products work routing function is integrated and inseparable 
from document storage and retrieval functions. 
What are the necessary functions and features? 65 

Issues to consider include the following: (1) samples and 
assists that are available to the developer; (2) existence of a 
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scripting or programming language; (3) granularity of the 
security, or in other words, at what levels can security be 
added; (4) freedom of choosing productivity applications; 
(5) existence of aggregate functions which allow for analysis 
of the workflow efficiency; (6) existence/need for Business 
Processing Re-engineering tools. 
How stable is the vendor? 

One should consider the leadership and size characteris- 
tics of the products vendor compared to the workflow 
software marketplace. Another consideration is whether the 
vendor is a member of Workflow Management Coalition. 
This coaltion is beginning to have a bigger impact on the 
direction of vendors workflow management products. 
How mature is the product? 

One should consider the age, release, and installed base of 
the product. 

How flexible is the product? 

A product should be able to support changing workflows 
at various levels of detail. 
Business Logic 1022,1024 

The execution architecture services are all generalized 
services designed to support the applications Business 
Logic. How Business Logic is to be organized is not within 
the scope of the execution architecture and must be deter- 
mined based upon the characteristics of the application 
system to be developed. This section is intended to serve as 
a reminder of the importance of consciously designing a 
structure for Business Logic which helps to isolate the 
impacts of change, and to point out that the underlying 
Netcentric architecture is particularly well suited for 
enabling the packaging of Business Logic as components. 

Business Logic is the core of any application, providing 
the expression of business rules and procedures (e.g., the 
steps and rules that govern how a sales order is fulfilled). As 
such, the Business Logic includes the control structure that 
specifies the flow for processing business events and user 
requests. There are many ways in which to organize Busi- 
ness Logic, including: rules-based, object-oriented, 
components, structured programming, etc. however each of 
these techniques include, although perhaps not by name, the 
concepts of: Interface, Application Logic, and Data Abstrac- 
tion. FIG. 33 depicts the various components of the Business 
Logic portion of the Netcentric Architecture Framework. 
Interface Logic (3302) 

Interface logic interprets and maps the actions of users 
into business logic processing activities. With the assistance 
of Presentation Services, Interface logic provides the linkage 
that allows users to control the flow of processing within the 
application. 

Application Logic (b2504) 

Application Logic is the expression of business rules and 
procedures (e.g., the steps and rules that govern how a sales 
order is fulfilled). As such, the Application Logic includes 
the control structure that specifies the flow for processing for 
business events and user requests. The isolation of control 
logic facilitates change and adaptability of the application to 
changing business processing flows. 
Data Abstraction (b2506) 

Information Access Services isolate the Business Logic 
from the technical specifics of how information is stored 
(e.g., location transparency, RDBMS syntax, etc.). Data 
Abstraction provides the application with a more logical 
view of information, further insulating the application from 
physical information storage considerations. 

The developers of business logic should be shielded from 
the details and complexity of other architecture services 
(e.g., information services, component services), and other 
business logic for that mater. 
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It is important to decide whether the business logic will be environment, although some business rules such as field 

separate from the presentation logic and the database access validation might still be tightly coupled with the presenta- 

logic. Today separation of business logic into its own tier is tion logic, the majority of business logic is separate, usually 

often done using an application server. In this type of an residing on the server. It is also important to decide whether 

environment, although some business rules such as field 5 tne business logic should be packaged as components in 

validation might still be tightly coupled with the presenta- order to maximize software re-use and to streamline soft- 

tion lgic, the majority of business logic is separate, usually wa [ e distribution. ... 
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• , j j * j *u i • * * machmes when changes to the business logic occur. If all the 
be stored and executed on the client; etc, . . . . ... . T. i- 
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Having the business logic stored on the server enables . L • j 
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developers to centrally mamtam application code; thereby , . 2 • u • i 
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. . , r .u *u *u r *• other hand, having the busmess logic execute on the client, 

business logic executes on the server, then the application on . 
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the client will make requests to the server whenever it needs ...... , , 6 TT lL ... , , , 

2 rj*. , , . . , initially launched. However, once the application is loaded, 

to execute a business function. This could increase network t J . , . t rr .. , . . 
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traffic, which may degrade application performance. On the 30 . , X. • j j , r C-* * • 

it _ ' , , . , , . i . . t t_ , „ with the server is needed. This type of an architecture might 

other hand, having the business logic execute on the client, . 4 , , . 4 . Jr . . t , . ..f. 

• i i j * ■ i . mtroduce complexities mto the application that deal with the 
may require longer load times when the application is . . c ; ; . . /f, , 
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most processing is done on the client until synchronization „ A . ^ A . t . , TI „ 

. iU T • i i T*i-. * + c u * « • . , „ software distribution options must be considered. Usually 

with the server is needed. This type of an architecture might 35 . . ... . ■ ■ 4 . 

. . , , • » *i_ i- »• *u * j i *u7u the most expensive option is to have a system administrator 

mtroduce complexities mto the application that deal with the . . • ,, • , t / j j . 
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sharing of and reliance on central data across many users. . . J . J . 4 rr u . A 4l _ r t . 
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If the business logic is stored and executed on the client, . . c. j- , l *• 

Cl j . .« , . 4 . , . ... n is to use a tool that performs automatic software distribution 

software distribution options must be considered. Usually . TT ... iL ^ 

4 , , . J - , . t » • • 4 . _ functions. However, this option usually requues the soft- 

the most expensive option is to have a system administrator 40 .. . /..r.jji. i_»-. 

4 . i_ • ii - * ii i* ^ j . ware distribution tool to be loaded first on each client 

or the user physically install new applications and update ,. A . . . . .. i . . , 

f. u i- * u- a +u ** machine. Another option is to package the application mto 

existing applications on each client machine. Another option __ . F ... . *^ 6 

* i 4i_ * r * *• f*, j. . >L »• ActiveX controls, utilizing the automatic install/update 
is to use a tool that performs automatic software distribution ..... . ' v . i f tL i- 

c TT .u- *• u • ,l r. capabilities available with ActiveX controls — if the appli- 

functions. However, this option usually requires the soft- f. . . , . - . , rr 

t - 4 . . i . L i j j c * u i- * cation is launched from a Web browser, 

ware distribution tool to be loaded first on each client 45 _ , ¥ . . ,. . . • fil _ 

. 4 , . 4 , t1 _ i* *• • * Currently, Internet applications house the majority of the 

machine. Another option is to package the application into , . J 1 . . rr . , • 

A t . v t . . ,r f »• ■ ♦ iw a * busmess processing logic on the server, supporting the 

ActiveX controls, utilizing the automatic install/update . . K j , rt * i_ i i .i.- 

...... A . v # , . f t . r thm-chent model. However, as technology evolves, this 

capabilities available with ActiveX controls — if the appli- , . .... . L . r . n • u • i • j 

cafion is launched from a Web browser. balances beginning to shtft, allowmg busmess .logic code 

Currently, Internet applications house the majority of the 50 bundled mt0 ""npooents to be either downloaded at runUme 

. . ' . , r . J- *u or permanently stored on the client machine. Today, client 

busmess processing logic on the server, supporting the . , v . . , . • ^ A tU u ,u r T 

thin-client model. However, as technology evolves; this s,de , busmess logic is supported through the use of Java 

balance is beginning to shift, allowing business logic code JavaBeans, Plug-ins and JavaScnpt from Sun/ 

bundled into components to be either downloaded at runtime Netscape and Act.veX controls and VBScript from 

or permanently stored on the client machine. Today, client 55 lcroso 

side business logic is supported through the use of Java Patterns 

applets, JavaBeans, Plug-ins and JavaScript from Sun/ Overview of Patterns 

Netscape and ActiveX controls and VBScript from Introducing Patterns 

Microsoft. The goal of patterns within the software community is to 

The developers of business logic should be shielded from 60 create a body of literature to help software developers 

the details and complexity of other architecture services resolve common difficult problems encountered throughout 

(e.g., information services, component services), and other all of software engineering and development. Patterns help 

business logic for that matter. create a shared language for communicating insight and 

It is important to decide whether the business logic will be experience about these problems and their solutions. For- 

separate from the presentation logic and the database access 65 mally codifying these solutions and their relationships lets 

logic. Today separation of business logic into its own tier is us successfully capture the body of knowledge which com- 

often done using an application server. In this type of an prises one's understanding of good architectures that meet 
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the needs of their users. Forming a common pattern lan- The pattern has a significant human component .... All 

guage for conveying the structures and mechanisms of software serves human comfort or quality of life; the 

architectures allows us to intelligibly reason about them. The best patterns explicitly appeal to aesthetics and utility, 
primary focus is not so much on technology as it is on 

creating a culture to document and support sound engineer- 5 Component-Based Development 

ing architecture and design. Introduction to Component Based Development, 

What is a Pattern? Component systems model — how the business works 

A pattern is a named nugget of insight that conveys the Component-orientation is a strategic technology that may 
essence of a proven solution to a recurring problem within significantly impact a user's practice and clients. Compo- 
a certain context amidst competing concerns. Patterns are a iQ nent technologies are a natural evolution from object- 
more formal way to document codified knowledge, or rules- oriented systems providing a more mature way of packaging 
of- thumb. reusable software units. Object-oriented systems more 

Patterns represent the codified work and thinking of our closely support business integration framework for solution 

object technology experts. While experts generally rely on delivery by shifting design focus away from an underlying 

mental recall or rules-of-thumb to apply informal patterns as technology toward a company's business conduct and func- 

opportunities are presented, the formalization of the patterns 15 lional behaviors. Business entities are represented as objects, 

approach allows uniform documentation and transfer of which package data and functional behavior. This is in 

expert knowledge distinct contrast to traditional development approaches that 

Patterns are not unique to object technology or even maintain a ubiquit0U s split between functional behaviors and 
software development, having been invented by Christopher . ^ r 
Alexander, a building architect. However, they have not 20 ' . . . , . t 
been applied to other information technology development Object-orientation has accelerated into the take-up curve, 
techniques. Thus, they are an exclusive feature of object M of tne ma J or commercial component models are object- 
technology. Furthermore, patterns are becoming widely oriented. In addition, all of the major vendors have adopted 
accepted by the worldwide object community as an impor- lhe "Unified Modeling Language" (UML) as a standard 
tant element in successfully rolling out the technology, and 25 notation for describing object models. A tremendous reser- 
enabling the maturation of software development as an voir of knowledge capital, practice aids and starter kits 
engineering process. related to object and component technology can be found on 

Patterns are usually concerned with some kind of archi- the Knowledge Exchange, 

tecture or organization of constituent parts to produce a More and more, users are asking for assistance to deploy 

greater whole. Richard Gabriel, author of Patterns of Soft- 3Q Netcentric eCommerce applications based on components. 

ware: Tales From the Software Community, provides a clear These applications are frequently based on object-oriented 

and concise definition of the term pattern: languages like Java, Visual Basic and C++. 

Each pattern is a three-part rule, which expresses a Objects are an easy metaphor to understand and manage, 

relation between a certain context, a certain system of There are still substantial risks involved, particularly 

forces which occurs repeatedly in that context, and a because component- and object-orientation has a pervasive 

certain software configuration which allows these 35 impact on areas as broad as analysis and design, planning, 

forces to resolve themselves. and development tools. 

As an element in the world, each pattern is a relationship Component -Based Overview 

between a certain context, a certain system of forces Component Technology Impacts Most Aspects of Develop- 

which occurs repeatedly in that context, and a certain m ent 

spatial configuration which allows these forces to 40 Component and object technology impacts most aspects 
resolve themselves. of software development and management. Component 
As an element of language, a pattern is an instruction, technology is a new technology and a driving influence in 
which shows how this spatial configuration can be the evolution of object-oriented (00) methodologies. The 
used, over and over again, to resolve the given system ^ Management Considerations section of the Introduction to 
of forces, wherever the context makes it relevant. Component -Based Development uses the Business Integra - 
The pattern is, in short, at the same time a thing, which tion (BI) Model to discuss the impact of 00, including: 
happens in the world, and the rule which tells us how Strategy and planning with a long-term view towards 
to create that thing, and when one must create it. It is building reusable, enterprise software assets, 
both a process and a thing; both a description of a thing 5Q Technology and architecture approaches for building 
which is alive, and a description of the process which cohesive, loosely coupled systems that provide long- 
may generate that thing. term flexibility. 
In Software Patterns, Jim Coplien writes, a good pattern Processes that shift analysis/design techniques from 
may do the following: functional, procedural decomposition to business pro- 
It solves a problem: Patterns capture solutions, not just 55 ^ modeling. These techniques are then used to 
abstract principles or strategies. decompose the system into domain objects and pro- 
It is a proven concept: Patterns capture solutions with a cesses. 

track record, not theories or speculation. People and organization strategies that emphasize greater 

The solution isn't obvious: Many problem-solving tech- specialization of skills within structures that support 

niques (such as software design paradigms or methods) 60 inter-team collaboration. 

try to derive solutions from first principles. The best Balancing Tradeoffs Is Key To Applying Components for 

patterns generate a solution to a problem indirectly — a Mission-Critical Systems 

necessary approach for the most difficult problems of Tradeoffs are an important theme. Experience with large, 
design. mission-critical systems has shown that the most complex 
It describes a relationship: Patterns don't just describe 65 issues require strategic tradeoffs between quality, cost, and 
modules, but describe deeper system structures and time. These tradeoffs usually involve interdependent con- 
mechanisms, siderations between strategy, technology, process, and 
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people. See FIG. 34 which illustrates a relationship between 
major themes. For example, how should an architecture be 
tailored to effectively support a specific methodology, for a 
given organization's skill set? Competing tensions also 
cloud decisions at a more detailed level. For example, how 
should an architecture be customized to better support 
performance, at the potential cost of increased coupling 
between components? 

Many of these considerations have been addressed over 
the last few years. Most published literature continues to 
focus on narrow technology issues, such as programming 
techniques or generic methodologies, such as analysis and 
design approaches or notation. Still, a growing number of 
publications and vendor strategies attack the enterprise 
needs within on-line netcentric execution models. Real- 
world, client solutions involve making pragmatic decisions, 
in which compromise occurs at the intersection of the four 
major 00 themes. Experience with many component client 
projects in diverse industries uniquely positions a user to 
effectively address these complexities. 
Management Considerations Overview 

The Management Considerations section discusses the 
key benefits, risks, and issues introduced by a component 
engagement. Key topics include: 

Managing risk in balancing tradeoffs between strategy, 
people, process, and technology 

Considering issues related to configuration management, 
testing, and performance of object systems 

Addressing the component development learning curve 

Differences between development architecture consider- 
ations leveraging the advantages of a component indus- 
try. 

The Management Considerations section also address 
issues not unique to Component technology, including: 
Estimating, planning, and managing iteration 
Organizing and managing to achieve reuse of both archi- 
tecture and business logic 
Netcentric Patterns Overview 

Netcentric Patterns Focus On Application Frameworks 

Netcentric Patterns focus on how to design and leverage 
application frameworks, which are pieces of reusable appli- 
cation architecture that provide a highly configurable, flex- 
ible and maintainable system. They are aligned with SAF 
and/or DAF service layers. Alignment with SAF and/or 
DAF makes the patterns easier to grasp the context for which 
they are solving problems. 

There was no mandate to express implementation within 
any given particular 00 language. Java and Visual Basic 
have increased in popularity over the last few years and C++ 
continues to be a solid foundation on which to build many 
types applications. In addition, some implementations chose 
the design syntax of UML. One should see the value of the 
pattern regardless of the implementation personality. 
Nowhere has this been more strongly demonstrated than in 
the Eagle Starter Kits. Here, the Eagle Architecture Speci- 
fication has been documented in patterns and implemented 
in Visual Basic, Java, C++ and a host of execution environ- 
ments within these language offerings. The power is in the 
reusable design patterns. 

For a high-level description of the context for the patterns 
within a service layer of SAF and/or DAF, click the title of 
the section. Please refer to the SAF and/or DAF for more 
detailed descriptions of the service layers. From the Frame- 
works Main Page, under Framework Extensions, the "Com- 
ponent Technology Extension" describes, in the context of 
the Netcentric Architecture framework, the additional, 
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specialized, architecture services that are required when 
building a system using component technologies. 
Approach 

Over the past years, component-based development has 
5 become an important, but often-misunderstood concept in 
the IT world. Components in themselves don't guarantee 
successful business applications, but coupled with a proven 
methodology and continuous technological advancements, 
they make it possible to realize a number of important 
10 benefits such as flexibility, adaptability, maintainability, 
reusability, integration readiness, interoperability, and scal- 
ability. 

Components have been around for a long time. The 
wheels on an ancient Roman chariot were certainly compo- 

15 nents. When the local chariot maker invented a new wheel 
(one that promised greater speeds and improved reliability 
on a wider variety of terrain), chariot owners would replace 
their worn-out, inefficient, and out-dated wheels with the 
new ones, but only if the new ones offered, at a minimum, 

20 the same function (i.e., rolling) through the same interface 
(i.e., the connection between the wheel and the chariot). 

Today components are used to build everything from cars 
to computers. In electronics, for example, they have led to 
the proliferation of product features, disposability, 

25 miniaturization, product selection, price reduction, and stan- 
dard interfaces — all good for the consumer. This example 
also draws attention to some of the challenges that accom- 
pany components: setting standards, determining the right 
components, the need to change standard interfaces based on 

30 new requirements, and the legal and commercial structure 
for selling components. 

Throughout the industry the word "component" is used 
broadly and often loosely. Components come in a wide 
variety of shapes and sizes. For example: JavaBeans, 

35 ActiveX controls, and COM objects. And more generically; 
application, architecture, development, engineering, Web, 
server, and business components. 

Many industry experts have attempted to define "compo- 
nent." Unfortunately, many of these definitions are too 

40 abstract, too academic, or too specialized to be useful. Yet 
below the surface of these definitions is some real business 
value for organizations. 

Experience has shown that it's quite common for people 
to view components from different perspectives, as illus- 

45 trated in FIG. 35. Some of them — typically designers — take 
a logical perspective. They view components as a means for 
modeling real -wo rid concepts in the business domain. These 
are Business Components. Others — typically developers — 
take a physical perspective. They view components as 

50 independent pieces of software, or application building 
blocks, that implement those real-world business concepts. 
These are Partitioned Business Components. Developers 
also emphasize that Partitioned Business Components can 
be built from other independent pieces of software that 

55 provide functionality that is generally useful across a wide 
range of applications. These are Engineering Components. 

To use an analogy, the designer of a PC workstation would 
initially think in terms of logical components such as Disk 
Storage, Memory, Display, etc. These are analogous to 

60 Business Components. At some point in the design process, 
however, this thinking must become more precise. For 
example, Disk Storage might become a Hard Disk Drive and 
Disk Controller Card. These are analogous to Partitioned 
Business Components. And finally, the designer might-use 

65 generic parts in the design of the Disk Controller Card, such 
as Memory Chips for cache, Bus Adapters, etc. These are 
analogous to Engineering Components. 
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Establishing one definition to satisfy all of these perspec- FIG. 36 shows a relationship between business compo- 

tives is certainly not required to be successful with compo- nents 3600 and partitioned business components 3602. Busi- 

nents. What's more important is to recognize the different ness Components are an integral part of the previously 

perspectives and to understand when it's appropriate to talk discussed Framework Designs. Business Components rep- 

about a particular type of component. Hence, multiple 5 resent real-world concepts in the business domain. They 

definitions, one for each type of component: encapsulate everything about those concepts including 

Business Components represent real-world concepts in name > P u rP ose . knowledge, behavior, and all other intelli- 

the business domain. They encapsulate everything about gence. 

those concepts including name, purpose, knowledge, , In the Business Architecture stage 3604, a project team 

behavior, and all other intelligence. Examples include: 10 be 8 ms i l ° l de . fin6 ^ W !<* ll0 ° architecture for an orgam- 

n a r\ j i f n - ^j.-oui zation s business capabilities using Business Components. 

Customer Product Order, Inventory, Pricing , Credit Check, Components model real-world concepts in the 

Billing, and Fraud Analysis. One might think of a Business business dom F ain ( cusl0 mers, products, orders, 

Component as a depiction or portrait of a particular business mveDtory , pricing, credit check, billing, and fraud analysis), 

concept, and as a whole, the Business Component Model is ^ is not the same as data modeling because Business 

a depiction or portrait of the entire business. It's also 15 Components encapsulate both information and behavior. At 

important to note that although this begins the process of this point in the process, an inventory of Business Compo- 

defining the application architecture for a set of desired nents is sufficient, along with a definition, list of entities, and 

business capabilities, the applicability of the Business Com- list of responsibilities for each Business Component, 

ponent Model extends beyond application building. In Capability Analysis 3606 and the first part of Capabil- 

Whereas Business Components model real-world con- 20 ity Release Design 3608, the project team designs Business 

cepts in the business domain, Partitioned Business Compo- Components in more detail, making sure they satisfy the 

nents implement those concepts in a particular environment. application requirements. The team builds upon its previous 

They are the physical building blocks used in the assembly work by providing a formal definition for each Business 

of applications. As independent pieces of software, they Component, including the services being offered. Another 

encapsulate business data and operations, and they fulfill 25 name for these services is "Business Component Interfaces." 

distinct business services through well-defined interfaces. The team also models the interactions between Business 

Business Components are transformed into Partitioned Busi- Components. 

ness Components based on the realities of the technical Throughout the remainder of Capability Release Design 

environment: distribution requirements, legacy integration, and into Capability Release Build and Test 3610, Business 

performance constraints, existing components, and more. 30 Components are transformed into Partitioned Business 

For example, a project team might design an Order Business Components based on the realities of the technical environ- 

Component to represent customer demand for one or more ment. These constraints include distribution requirements, 

products, but when it's time to implement this concept in a legacy integration, performance constraints, existing 

particular client/server environment, it may be necessary to components, and more. Furthermore, to ensure the concep- 

partition the Order Business Component into the Order 35 tual integrity of the Business Component model, a given 

Entry component on the client and the Order Management Partitioned Business Component should descend from one 

component on the server. These are Partitioned Business and only one Business Component. In other words, it should 

Components. never break the encapsulation already defined at the Busi- 

Engineering Components are independent pieces of soft- ness Component level. Also at this time, the project team 

ware that provide functionality that is generally useful 40 designs the internal workings of each Partitioned Business 

across a range of applications. They come in all shapes and Component. This could mean the Engineering Components 

sizes, and they are typically packaged as black box capa- that make up the Partitioned Business Component, the 

bilities with well-defined interfaces. They are the physical "wrapper" for a legacy or packaged system, and other code, 

building blocks used in the assembly of Partitioned Business In Capability Release Build and Test, Partitioned Business 

Components. Examples include: a workflow engine, a Java- 45 Components are built and tested. The build process varies 

Bean that encapsulates a reusable concept like address or depending upon the technology chosen to build the internal 

monetary unit, a complex widget that allows users to edit a workings of each Partitioned Business Component. Among 

list of order lines, a group of objects responsible for the many tests that are performed during this stage, the 

persistence, a JavaBean that sorts a collection of objects, and component, assembly, and performance tests are impacted 

a simple list box coded as an ActiveX control. 50 the most by this style of development, A component test 

Components are useful throughout the development pro- addresses a Partitioned Business Component as a single unit 

cess. As a design artifact, early in the process, Business by testing its interfaces and its internal workings, while an 

Components provide an underlying logical framework for assembly test addresses the interactions between Partitioned 

ensuring flexibility, adaptability, maintainability, and reus- Business Components by testing broader scenarios. The 

ability. They serve to break down large, complex problems 55 performance test is impacted primarily by the techniques 

into smaller, coherent elements. They also model the busi- one would use to resolve the various performance issues. For 

ness in terms of the real-world concepts that make up the example, it's common to run multiple copies of a Partitioned 

domain (e.g., entities, business processes, roles, etc.). Thus Business Component across multiple servers to handle a 

they provide the application with conceptual integrity. That greater transaction volume. 

is, the logical Business Components serve as the direct link 60 In Deployment 3612, the Partitioned Business Compo- 

between the real-world business domain and the physical nents are packaged and deployed as part of the application 

application. An important goal is to build an application that into the production environment. The application parameters 

is closely aligned with the business domain. Later in the and the manner in which the Partitioned Business Compo- 

process, Partitioned Business Components and Engineering nents are distributed are tweaked based on how well the 

Components provide a means for implementing, packaging, 65 application performs. 

and deploying the application. They also open the door to Well designed Business Components are anthropomor- 

improved integration, interoperability, and scalability. phic. That is, they take on characteristics and abilities as if 
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they were alive. This means that Business Components centric Business Components are "in control/ 1 while entity- 
should reflect directly the characteristics and abilities (i.e., centric Business Components do what they're told. To be 
the information and behavior) of the business concepts they more explicit, a process-centric Business Component con- 
represent. Therefore, only by examining the various types of trols the flow of a business process by requesting services in 
business concepts will one discover an acceptable way to 5 a specific sequence according to specific business rules (i.e., 
classify Business Components. conditional statements). The services being requested are 

Business concepts come in a wide variety. For example, generally offered by entity-centric Business Components, 
a product represents something of value that is up for sale; but not always. Sometimes process-centric Business Corn- 
while a credit check represents the work that needs to be ponents trigger other process-centric Business Components, 
done to determine if a customer's credit is good. The former 1Q FIG. 37 shows how a Billing Business Component 3700 
is centered around an entity — the product — while the latter may create an invoice. The control logic 3702 (i.e., the 
is centered around a process — credit check. sequence of steps and business rules) associated with the 

This line of thinking leads to two types of Business billing process is encapsulated within the Billing component 

Components: entity-centric and process-centric. itself. The Billing component requests services from several 

Unfortunately, what commonly results from this paradigm is entity-centric Business Components, but it also triggers 

an argument over whether or not a particular Business 15 Fraud Analysis 3704, a process-centric Business is 

Component is entity -centric or process-centric. In reality, Component, if a specific business rule is satisfied. Note also 

Business Components are always a blend of both informa- that "Step 6" is performed within the Billing component 

tion and behavior, although one or the other tends to carry itself. Perhaps this is where the invoice is created, reflecting 

more influence. An appropriate mental model is a spectrum the design team's decision to encapsulate the invoice within 

of Business Components. 20 the Billing component. This is one valid approach. Another 

Business Components on the entity-centric side of the is to model a separate entity-centric Invoice component that 

spectrum tend to represent significant entities in the business encapsulates the concept of invoice. This would effectively 

domain. Not only do they encapsulate information, but also decouple the invoice from the billing process which might 

the behaviors and rules that are associated with those be a good thing depending on the requirements, 

entities. Examples include: Customer, Product, Order, and 25 It would be logical to conclude that the two types of 

Inventory. A Customer Business Component would encap- Business Components translate to two types of Partitioned 

sulate everything an organization needs to know about its Business Components, but a small adjustment is required, 

customers, including customer information (e.g., name, Entity-centric Business Components translate directly to 

address, and telephone number), how to add new customers, Business Entity Components, but a closer look at the ways 

a customer's buying habits (although this might belong in a 30 in which a business process can be implemented in an 

Customer Account component), and rules for determining if application reveals two possibilities for process-centric 

a customer is preferred. Business Components. A business process can be: 1) 

Business Components on the process-centric side of the automated, like a billing process, or 2) controlled by a user, 

spectrum tend to represent significant business processes or like an order entry process. The former results in a Business 

some other kind of work that needs to be done. Not only do 35 Process Component, while the latter results in a User Inter- 

they encapsulate behaviors and rules, but also the informa- face Component. 

tion that is associated with those processes. Examples FIG. 38 illustrates the relationship between the spectrum 

include: Pricing, Credit Check, Billing, and Fraud Analysis. of Business Components 3800 and the types of Partitioned 

A Pricing Business Component would encapsulate every- Business Components 3802. Business Entity Components 

thing an organization needs to know about how to calculate 40 3804 and Business Process Components 3806 are straight- 

the price of a product, including the product's base price forward. The former is the physical implementation of an 

(although this might belong in a Product component), dis- entity-centric Business Component (e.g., Customer), while 

counts and rules for when they apply, and the calculation the latter is the physical implementation of an automated 

itself. process-centric Business Component (e.g., Billing). User 

One might argue that the Pricing component is more 45 Interface Components 3808, on the other hand, require 

entity-centric than process-centric. After all, it's centered further explanation. 

around the concept of price, which is an entity. In reality, As mentioned above, a User Interface Component is the 

though, it depends on the business requirements, but again, implementation of a business process that is user controlled, 

whether or not a given Business Component is entity-centric but more explicitly it is a set of functionally related windows 

or process-centric is not important yet. What is important is 50 that supports the processes) performed by one type of user, 

how well the Business Component represents its corre- Examples include: Customer Service Desktop, Shipping 

sponding real-world business concept. The fact that most Desktop, and Claim Desktop. These are not to be confused 

business concepts are a blend of information and behavior with low-level user interface controls (e.g., Active X 

means that most Business Components should also be a controls), rather User Interface Components are usually built 

blend of information and behavior. Otherwise applications 55 from low-level user interface controls. The reason for the 

would be much like they are today with a distinct separation dashed arrow in the diagram above is a subtle one. It points 

of data and process. to the fact that earlier in the development process User 

Another way to think about the process-centric side of the Interface Components are generally not modeled as process- 
spectrum is by asking, "What role performs the process?" centric Business Components. Instead, they typically origi- 
For example, it's the picker-packer who picks inventory and 60 nate from the workflow, dialog flow, and/or user interface 
packs it into a shipment. This might lead to the Picker- designs. See FIG. 39, which illustrates the flow of workflow, 
packer component. Another example is a Shopping Agent dialog flow, and/or user interface designs 3902, 3904, 3906 
component that knows someone's buying preferences, shops to a User Interface Component 3908. This makes complete 
for the best deals, and either reports back to the user or sense given their direct tie to user controlled business 
makes the purchase. 65 processes. 

A pattern emerges when one examines the way these FIG. 40 is a diagram of the Eagle Application Model 

Business Components interact with each other. Process- which illustrates how the different types of Partitioned 
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Business Components might interact with each other. Busi- 
ness Entity Components 4002 and Business Process Com- 
ponents 4004 typically reside on a server, while User Inter- 
face Components 4006 typically reside on a client. 

FIG. 41 illustrates what makes up a Partitioned Business 
Component 4100. As long as a component does what it's 
suppose to do, it doesn't matter what kind of code is used to 
build the component's internal workings. It could be any- 
thing from COBOL to Java. This is a key benefit of 
encapsulation. Classifying this code is a different matter. 
Some code 4102 is specific to the Partitioned Business 
Component. Other code is more widely reusable, both 
functionally and technically; this is where one finds Engi- 
neering Components 4104. Another possibility is to "wrap" 
existing code 4106 from legacy and packaged systems. 
Finally, it's important to note that patterns and frameworks 
are frequently used as starting points for designing and 
building this code. 

Engineering Components are physical building blocks 
used in the assembly of Partitioned Business Components. 
They are independent pieces of software that provide func- 
tionality that is generally useful across a range of 
applications, and they are usually packaged as black box 
capabilities with well-defined interfaces. Engineering Com- 
ponents can be bought or built, and they come in a wide 
variety. Examples include: a workflow engine, a JavaBean 
that encapsulates a reusable concept like address or mon- 
etary value, a complex user interface control that allows 
users to edit a list of order lines, a group of objects 
responsible for persistence, a JavaBean that sorts a collec- 
tion of objects, and a list box coded as an ActiveX control. 

A pattern is "an idea that has been useful in one practical 
context and will probably be useful in others." Think of them 
as blueprints, or designs for proven solutions to known 
problems. Having found the right pattern for a given 
problem, a developer must then apply it. Examples of 
patterns include: an analysis pattern for hierarchical rela- 
tionships between organizations and/or people, a design 
pattern for maintaining an audit trail, a design pattern for 
applying different levels of security to different user types, 
and a design pattern for composite relationships between 
objects. 

A framework is a template for the implementation of a 
particular function (similar to a shell program). It usually 
embodies a known pattern (or group of patterns) in a specific 
technical environment. Frameworks are available from a 
number of third-party vendors, and they are also developed 
on projects. Developers are typically expected to customize 
and extend frameworks to meet their specific requirements, 
but this involves a tradeoff. Customizing and extending a 
framework may optimize its use, but the resulting frame- 
work tends to be less abstract, and therefore less reusable in 
other contexts. Examples of frameworks include: a frame- 
work for displaying an object and its properties in Smalltalk, 
a Java-specific framework for persisting data, and a mes- 
saging and publish/subscribe framework for DCOM 

FIG. 42 illustrates the role of patterns and frameworks. 
More specifically, it introduces the Eagle Architecture 
Specification 4200 and the Component Solutions Handbook 
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applications have become more difficult and time- 
consuming to build and maintain. Looking forward, appli- 
cations must be dramatically more responsive to change. 
They must be more: 



20 



45 



50 



55 



In theory . 



In practice . 



Flexible 



10 



Making it possible to quickly 
satisfy new business require- 



Making it possible to 
accommodate a new 



ments by replacing or modifying product line solely by 



Adaptable 



15 



certain components with 
minimal impact to others. 
Making it easy to deliver an 
application to a variety of user 
types through a variety of 
delivery channels with minimal 
impact to the core application. 



Maintainable Making it easy to update an 

application by reducing the area 
of impact for most changes. 



Reusable Making it possible to quickly 
assemble unique and dynamic 
solutions from existing 
25 components. 



Integration Making it possible to reuse the 
Ready functionality within existing 

30 systems by wrapping them as 

components within new 

applications. 



Interoperable Making it possible to request 
services across platforms. 



Scalable Making is easy to distribute and 
reconfigure components to 
satisfy various transaction 
volumes. 



updating the Product 
component. 

Making it easy to provide 
in-home access to 
customer account infor- 
mation by developing 
only a new user interface 
while reusing existing 
components. 
Making it easy to add a 
new customer attribute 
by isolating the change to 
one component- the 
Customer component 
Making it possible to 
assemble an application 
at a fraction of the cost 
because eight of the 
twelve components that 
are needed already 
exist 

Making it possible to 
absorb newly acquired 
divisions by "wrapping" 
their systems and 
"plugging" them into 
the enterprise infra- 
structure. 

Making it possible to 
integrate two applications 
built on different plat- 
forms. 

Making it easy to 
accommodate the holiday 
crunch by running 
multiple copies of the 
Order component across 
multiple servers. 



Components will help an IT organization achieve these 
quality attributes. Through encapsulation they make it pos- 
sible to develop applications that are more responsive to 
change. One can make this claim with confidence because a 
component that is well encapsulated (i.e., an independent, 
black box component with predictable, well defined 
interfaces) can be used in any situation, as long as it's used 
for its intended purpose. It knows how to perform its 
services without regard to what's happening outside of its 
boundaries (e.g., the actions that precede or follow it). 

Another key to embracing change is the predictability and 
conceptual integrity of the parts that make up an application. 
Fred Brooks, author of The Mythical Man-Month, 
writes, "... conceptual integrity is the most important 
consideration in system design." Therefore, components 
must be conceptually whole, and they must perform func- 



tions that are aligned with their purpose and within their 
4202, both of which are groups of patterns. Eagle also offers 60 sphere of knowledge. If they accurately reflect the real 



technology-specific starter kits 4204, which include frame- 
works for various environments. 

The pace of change in today's business world is increas- 
ing faster than ever before. Meanwhile, advances in infor- 
mation technology have enabled businesses to better under- 
stand their customers, provide greater value, and create new 
markets. However, as technology becomes more complex, 



65 



world, they are much easier to develop and maintain. If the 
real world changes, so must the corresponding component. 

Given a design with these characteristics, the opportunity 
for reuse is significantly enhanced, and the time it takes to 
upgrade the system is dramatically reduced. The Gartner 
Group agrees that component-based development will be a 
dominant method of application development in the years to 
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come. They say that "by 2001, at least 60 percent of all new 
applications development will be based on assemblies of 
componentware, increasing speed to market and the ability 
to cope with change (0.7 probability)." 

Business Components and Partitioned Business Compo- 
nents represent a major improvement in design capability — 
some might argue the first major change in design thinking 
since structured design. There are several reasons for this 
breakthrough: 

Business Components model entities and processes at the 
enterprise level, and they evolve into Partitioned Business 
Components that are integrated into applications that operate 
over a network. Consequently, they serve as an excellent first 
step in the development of scalable, distributed enterprise 
applications that map closely to the business enterprise itself 
(i.e., the way it operates and the information that defines it). 

Business Components model the business, and thus they 
enable applications to more completely satisfy the business 
needs. They also provide a business-oriented view of the 
domain and consequently a good way to scope the solution 
space. This results in a good context for making process and 
application decisions. Finally, Business Components pro- 
vide a common vocabulary for the project team. They 
educate the team in what's important to the business. 

When modeled correctly, entity-centric Business Compo- 
nents represent the most stable elements of the business, 
while process-centric Business Components represent the 
most volatile. Encapsulating and separating these elements 
contributes to the application's overall maintainability. 

To manage the complexity of a large problem, it must be 
divided into smaller, coherent parts. Partitioned Business 
Components provide an excellent way to divide and conquer 
in a way that ties the application to the business domain. 
They provide the ability to "package software capabilities 
into more manageable (and useful) chunks." By contrast, 
traditional modules are too cumbersome to be reusable in 
multiple contexts. On the other end of the spectrum, objects 
are too small to effectively divide and conquer; there are 
simply too many of them. 

Partitioned Business Components provide a greater 
emphasis on application layering-a well known, but often 
neglected concept in application development. 

Partitioned Business Components are application building 
blocks. As an application modeling tool, they depict how 
various elements of an application fit together. As an appli- 
cation building tool, they provide a means for systems 
delivery. 

Proven processes, patterns, and frameworks offer a higher 
level of reuse. This is one of the key advantages because it 
means greater agility. These mechanisms make it possible 
for hundreds of developers to do things consistently and to 
benefit from previously captured, reusable knowledge capi- 
tal. 

Business Components model the business. It sounds 
straightforward, but even with experience it's a challenge to 
identify the right components and to design them for flex- 
ibility and reuse. Flexibility and reuse are certainly more 
achievable with Business Components, but they are not 
inherent to Business Components. To accomplish these 
goals, as the previous examples suggest, one must under- 
stand what's happening within the enterprise and across the 
industry. One must work with business experts who under- 
stand the factors that will influence the current and future 
evolution of the business domain. This will improve one's 
ability to anticipate the range of possible change (i.e., to 
anticipate the future). The Business Component Model will 
be more flexible and reusable if it is challenged by scenarios 
that are likely to take place in the future. 
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Reuse becomes a reality more quickly if one plans for it. 
And it endures if one manages it over time. However, both 
of these things are difficult to do, especially for large projects 
and large enterprises. First of all, it's easy for communica- 

5 tion across one or more projects to break down. It's also 
common for individual projects to pay more attention to 
their requirements and deadlines than to project-wide or 
enterprise- wide reuse. After all, their most important objec- 
tive is to deliver value to their customers. Reuse must be 

10 engrained into the culture. This could mean teams respon- 
sible for project-wide and enterprise-wide reuse, but no 
matter how it's done, reuse must be one of the most 
important technology objectives. 

Too much focus on low- level (i.e., code) reuse can be a 

15 trap. To draw an analogy, take a look at the recent history of 
the auto industry. Some auto makers were focused on 
inter-changeable parts and low-level standardization. For 
example, they decided to use the same body style for all of 
their cars. Unfortunately, when the industry began to move 

20 away from the boxy body style, they were not well prepared, 
nor were they agile enough to react in a timely fashion. They 
had invested too much in low- level standardization. 
Conversely, other auto makers were focused on quality 
processes and frameworks (i.e., high-level reuse). As a 

25 result, they were able to respond more quickly to the 
changing requirements. Engagement experience has shown 
that the same thing can happen with components and objects 
(e.g., too much emphasis on low-level inheritance). That's 
why it's important to focus appropriately on the high-level 

30 reuse enabled by processes, patterns, and frameworks. 

Although Business Components and Partitioned Business 
Components represent a significant breakthrough in design 
capability, the architectural frameworks to support this 
breakthrough are still maturing. Standards come to mind 

35 first: Will it be COM, JavaBeans, or CORBA? It's still not 
clear. Likewise with languages: Will it be Visual Basic, 
Java? Tools and repositories offer another challenge. Clear 
winners have yet to emerge, and newcomers are constantly 
popping up with promising products. Finally, the legal and 

40 commercial market for buying and selling components is not 
mature. The market for high-level common business objects 
is just emerging, while the market for low-level components 
is still chaotic. 

One of the most important challenges is teaching a new 

45 application development style. Although components and 
objects have been around for a while, they are new to most 
people. Furthermore, component-based development 
requires a change in the way one thinks about designing and 
building applications. Engagement experience has shown 

50 that it takes a couple of months to feel comfortable with this 
paradigm-and longer for those pursuing deeper technical 
skills. But this challenge is certainly not impossible to 
overcome. A combination of training and mentoring has 
proven to be the best way to teach these concepts, and the 

55 more rigorous approach that results from this education is 
well worth the journey. 

The following tips and techniques provide an introduction 
to some of the issues surrounding the design of Business 
Components. 

60 What is the right number of Business Components? How big 

should they be? 

The granularity of Business Components is a frequent 

topic of discussion. A fairly common misconception is that 

Business Components are the same as applications, but in 
65 fact, applications are assembled from Business Components 

(or Partitioned Business Components to be more accurate). 

A typical application might have ten to twenty Business 
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Components. On the other end of the spectrum, Business 
Components are larger than business objects. In fact, some 
people refer to Business Components as large-grained busi- 
ness objects. 

So what is the right size for a Business Component? 

Business Components should encapsulate concepts that 
are significant to the business domain. Of course, this is 
subjective, and it certainly varies by business domain. In 
fact, business domain experts, with help from component 
modelers, are in the best position to make this judgment. 

Bigger Business Components hide more complexity, 
which in general is a good thing. However, too much 
complexity in a component can lead to many of the problems 
that preceded component-based development. For example, 
embedding too much policy information can lead to a 
Business Component that is more difficult to maintain and 
customize. Another advantage is the fact that the coupling 
between bigger components tends to be weaker. On the other 
hand, bigger components are generally less cohesive and 
consequently less flexible. For example, assume that the 
concepts of warehouse and inventory have been combined 
into one Business Component. This could be problematic if 
a future application needs warehouse information, but not 
inventory information. 

Smaller Business Component tends to be more flexible. 
It's also easier to reuse them in future applications. 
Unfortunately, smaller components typically result in a 
higher degree of coupling. One will find significantly more 
interactions between smaller components. This could also 
lead to performance problems. If two or three small com- 
ponents send each other a lot of messages, it might make 
sense to combine them into one. Smaller components may 
also be more difficult to manage, simply because more of 
them exist. 

It's important to strike a balance, and keep in mind that 
the ideal size depends on the domain. If there's a question 
in one's mind, it makes sense to lean toward smaller 
components. It's easier to combine them than to break them 
up. 

What's the best way to identify Business Components? 

During the Business Architecture stage, the project team 
defines its business capabilities. At this point in the process, 
one can begin to search the business domain for Business 
Components. Then again later, during Capability Release 
Design, when the project team documents scenarios and 
workflows, one can perform a second iteration through the 
identification process. 

The following steps describe one technique for identify- 
ing Business Components. FIG. 43 illustrates this Business 
Component Identifying Methodology 4300 including both 
Planning and Delivering stages 4302, 4304: 

1. Start with entity-centric Business Components. For 
example, the customer is a significant entity in most 
business domains, therefore a Customer component 
may be included. A Customer Business Component 
would encapsulate everything an organization needs to 
know about its customers, including customer infor- 
mation (e.g., name, address, and telephone number), 
how to add new customers, a customer's buying habits 
(although this might belong in a Customer Account 
component), and rules for determining if a customer is 
preferred. Entities themselves can be physical or con- 
ceptual. For example, customers and products are 
physical — you can touch them. Orders, on the other 
hand, are conceptual. An order represents a specific 
customer's demand for a product. You cannot touch 
that demand. 
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2. Look for process-centric Business Components next. 
Generally speaking, a process-centric Business Com- 
ponent controls the flow of a business process. For 
example, in the utility industry, a Billing component 

5 would process customer, product, pricing, and usage 
information into a bill. Sometimes one will find an 
entity associated with the process — in this case, a bill 
or invoice — but another option is to model this entity as 
a separate, entity-centric Business Component, thus 

10 decoupling it from the process. 

What's the best way to identify the responsibilities of a 
business component? 

Review the business capabilities, business processes, 
business practices, scenarios, workflows, and other require- 

15 ments. Look for behaviors that will be supported by the 
application. In other words, what are the business functions 
that will be performed by the system? Assign them as 
responsibilities to the most appropriate component. If com- 
ponents were people and computers didn't exist, one might 

20 ask, "Who is responsible for this task?" In fact, sometimes 
it's helpful to assign component owners who speak up when 
they encounter a responsibility that should belong to their 
components — "Hey, I should be responsible for that!" 
This section addresses several frequently asked questions 

25 that more broadly apply to the physical implementation of 
component- and object-based solutions. The answers are 
intended to increase the awareness of the reader. Most of 
them only scratch the surface of issues that are somewhat 
controversial within the component and object community. 

30 What is the role of components in net-centric computing? 
Physical components play a critical role in net-centric 
computing because they can be distributed, as encapsulated 
units of executable software, throughout a heterogeneous 
environment such as the Internet. They have the ability to 

35 make the Web more than a toy for retrieving and download- 
ing information. Robert Orfali, Dan Harkey, and Jeri 
Edwards, well-known experts in the field of component- and 
object-based development, wrote the following about dis- 
tributed objects (same as "distributed components" for the 

40 purpose of this discussion): 

The next -gene ration Web — in its Internet, intranet, and 
extranet incarnations — must be able to deal with the com- 
plex requirements of multi-step business-to-business and 
consumer-to-business transactions. To do this, the Web must 

45 evolve into a full-blown client/server medium that can run 
your line-of-business applications (i.e., a delivery vehicle 

for business transaction processing) To move to the next 

step, the Web needs distributed objects. 

What's the difference between components and objects? 

50 From a logical perspective, components and objects are 
the same. They both model concepts from a particular 
domain, and they both encapsulate information and behav- 
ior. On this level, good component models and good object 
models share the same characteristics: high cohesion, low 

55 coupling, reusability, well defined services, and more. One 
might argue that granularity is a key difference. After all, for 
an object-oriented design, components are made up of 
objects. This may be true, but in reality both of them come 
in all sizes, thus making this difference rather insignificant. 

60 From a physical perspective, components and objects are 
similar, but different. The key difference relates to the 
different ways in which they are implemented. As long as a 
component's interfaces comply with an accepted standard 
like COM, JavaBeans, or CORBA, its internal workings can 

65 be implemented using any technology (e.g., Java, Visual 
Basic, Smalltalk, C, or even COBOL). The internal work- 
ings of an object, on the other hand, can only be imple- 
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merited using object technology. For the same reason (i.e., pany is installing an inventory management, system for 

standard interfaces), it is possible to request a component's tracking pagers, while another part of the company is trying 

services from any platform. That's not true of objects, unless to determine how to track the frequencies that are owned and 

they are wrapped with interfaces that comply with the leased by the company. What does this company mean by 

accepted standards, which would make them distributed 5 inventory? Does it simply mean knowing what items are in 

objects (i.e., components) instead. a warehouse? 

Robert Orfali, Dan Harkey, and Jeri Edwards also wrote When the company thinks abstractly about the concept of 

the book The Essential Distributed Objects Survival Guide inventory, they discover that it's all about managing any- 

(1996). Chapter 2, "From Distributed Objects to Smart tnuig 0 f value. When they look at what they have in 

Component," is an excellent source of information about 1Q mventory> y^y disc over that it is countable, reservable, and 

objects, components, and the differences between them. has a cost ^ it . Inventory does not require 

They say the following about physical components: dfic of the ^ of m item m mveat ory; that 

A component is an object that s not bound to a particular knowledge can be put into another component, such as Item, 

program, computer language, or implementation . Tf invento does not need t0 know the ifics a5out its 

They are the optimal building blocks for creating the ^ u £ 

next generation of distributed systems .... Compo- J:> . 4 . *a ' . . , * ' . , ' , . 

nents are standalone objects that can plug-and-play lt « «oaated with. Inventory could be used to 

across networks, applications, languages, Tools, and mana S e a vanety of things: conference rooms, fixed assets, 

operating systems. Distributed objects are, by work in P rocess > fimshed g°° ds ' and Ieased fluencies, 

definition, components .... Unlike traditional objects, So one can start oul building an inventory management 

components can interoperate across languages, tools, 20 application and then build the ready-to -reuse Inventory 

operating systems, and networks. But components are component which, without modification, can support many 

also object-like in the sense that they support other uses. In this way one can unload the concept of 

encapsulation, inheritance, and polymorphism. inventory so that it can be reused outside the context it was 

What is a component model? initially planned for. 

This is a common point of confusion. From a logical 2 5 This section highlights key messages for project manage- 

perspective, the term "component model" is frequently used meQtt The Management Lessons discuss these points further, 

to refer to a Business Component Model in the same way Manage Expectations— Component Technology Is Not a 

that "object model" is used to refer to a business object silver Bullet 

mode ^ ... . * , / Components promise to enhance the ability to quickly 

From a physical perspecUve, a component model (or a 3Q build robust ^ thr b the use of reusaWe buiu 

component obiecl model) defines a set of conventions that «. * n i i j . 

. , * j j * j i j l i software components. Properly leveraged, components can 

provides a standard way to develop and use physical • j i_ r j • 1 • L j j • 

components, including how to-define properties, events, P rovide , *c foundation upon which one meet and exceed the 

behaviors, etc. It also includes the standard structure of a demands of a ^ obal marketplace which increasingly uses 

component's interfaces, the mechanism by which a compo- technology as a primary competitive advantage. Like object 

nent interacts with other components, patterns for asking a 35 technology before, components are often portrayed as the 

component about its features, a means for browsing active ma S ic silver bullet to slav lne ills of software technology, 

components, and more. Some of the existing component Yet, the silver bullet mentality inevitably leads to unrea- 

models are COM, JavaBeans, and CORBA. sonable expectations. Intense media attention fuels these 

expectations. For example, components are often compared 

Example: A Grocery Store 4Q to Ug0 blocks lhat are simply p i ugged together to form 

A grocery store chain is creating an enterprise- wide complex systems. Experience has shown, however, that 
Business Component model. Currently the individual stores component technology is not that simple and that payoffs are 
do not record specific customer information. primarily in the long term. There are several factors impede 

Consequently, a model based on today's requirements short-term payoffs, 
would not retain customer information. 45 Most important, demand exceeds supply for professionals 

However, they are looking into preferred customer cards. with component and object-oriented skills. Thus, many 
Furthermore, while analyzing the industry, the project team initial projects incur start-up costs related to recruiting, 
reads about a competitor with a pharmacy and video rental training, and learning curve. Furthermore, after receiving 
service. In both cases, customer information becomes criti- investment in training, individuals find themselves in 
cal. So the project team creates scenarios describing how 50 demand, becoming higher risk to leave the organization, 
they would use customer information to support these Another unreasonable expectation is the belief that corn- 
requirements. They create one Business Component Model ponents may provide immediate software reuse. Experience 
that supports both today's and tomorrow's view of the has shown that reuse is not automatically attained; it is 
customer. necessary to establish a disciplined approach to reuse and 

In the near future, when the chain adopts preferred 55 create a development culture that embraces reuse, 
customer cards, and in the more distant future, if they decide A client's view of component technology may vary 
to add a pharmacy or video rental service, the Business depending on their previous experiences. Client's with no 
Component design for their current application will provide component or object experiences may have the most unre- 
a solid foundation for the future requirement of tracking alistic expectations for what the technology can delivery. In 
customer information. If they weren't using Business 60 contrast, clients that have attempted object-oriented appli- 
Components, they would not have a model that maps to their cations and failed may understand that components are not 
business domain, and introducing new requirements would the "silver bullet" that many have promised. In fact, these 
require more abrupt changes. clieDts ma y require additional evidence of the viability of a 

component approach. For these clients, a component 
Example: Inventory Management 65 approacn can be very appealing since a component-based 

A telecommunications company in the paging business architecture can combine both traditional and object tech- 
sells and leases pagers and services. One part of the com- nologies. And lastly, there is the third category of clients that 
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have achieved some measure of success with object tech- 
nology and view component technology as the natural 
evolution towards the goals that are only partially delivered 
by object technology alone. 

Component-based Development's Focus on the Long-term 
Is Usually a Good Tradeoff 

Component-based development is also inherently biased 
towards the long-term. For example, the development pro- 
cess strives for a higher degree of quality and reuse, incor- 
porating iteration between design and code to support refine- 
ment. Striving for this higher design quality may almost 
always, by definition, cost more up front. Despite these 
initial costs, component-based development's focus on the 
long-term makes economic sense. Experience has shown 
that 60-80% of development costs are in maintenance. 
Recruit a Project Champion or Sponsor with a Long-term 
Focus 

To ensure that short-term concerns do not outweigh the 
potential benefits, project management should maintain a 
realistic view of the benefits and risks of components. Thus, 
recruiting a project champion or sponsor with a balanced, 
long-term view is a key to success. 

Business Benefits Must Support Adoption of Component 
Technology 

Establish Clear Goals for a Component-based Project 

Component technologists sometimes promote component 
development for its own sake, without regard for the busi- 
ness benefits. However, rarely may management justify 
something they do not understand. Component technology 
introduces a daunting array of new terminology. 
Furthermore, if a pilot component project is launched with 
unclear goals or mission, the significant short-term costs and 
challenges may inevitably undermine the commitment to 
components. 

Thus, component technology must be justified in business 
rather than technology terms. In many cases, a traditional 
client/server solution can deliver the benefits. This proves 
especially true for short-lived, simple, or moderately com- 
plex applications. On the other hand, component technology 
may benefit applications with characteristics such as: 

a long maintenance life 

complex processing or significant asynchronous logic 

complex data relationships 

very dynamic business requirements 

multiple access channels 

legacy evolution or replacement 

functionality common across multiple applications 
Firm Clients Have Achieved Business Benefits 

The number of engagements that have employed compo- 
nent and object technologies has continued to grow over the 
last few years. These engagements have shown that object 
and component-based approaches can lead to significant 
business benefits. 
Reduces Maintenance Costs 

Properly designed component-based systems should 
reduce maintenance costs. Encapsulating implementation 
details and data make a system more resilient to changes in 
the business or underlying technology. Furthermore, design 
decisions must rigorously consider what is likely to change. 
Susceptible points should be hidden behind an abstract, 
public interface that decouples their potential changes from 
impacting other components. 
Component Reuse Reduces Development Time 

Components are more easily reused because they provide 
well-defined interfaces and can often be used through visual 
development tools. This make it more straightforward to 



^8,068 Bl 

140 

develop components for one project and share them across 
other projects. Furthermore, components can be designed so 
that their properties can be tailored to meet varying require- 
ments. Once a reusable base of components has been 

5 established, the development time for subsequent projects 
can be reduced. 

In one utility company they saw significant gains in the 
reuse of components across initiatives. Rather than copying 
and tailoring source code for new initiatives they were able 

10 to assemble applications from already created components. 
Another engagement estimated that new system develop- 
ment was reduced 25% once the first application was 
released and a core set of components was established. Even 
though the engagement ultimately realized the benefits of 

is reuse, the client still had the expectation that reusable 
components would save time and money for the first project. 
To manage this expectation, the project team needed to 
re -emphasize that component-based development requires 
an initial investment, 

20 Leverage Existing Technology Investments 

Many clients have existing technology assets that would 
require significant investments to replace. Components can 
enable these legacy systems to be wrapped with component 
interfaces so that new applications can easily interact with 

25 them. Later, these legacy applications could be replaced 
without changes to the new applications. 
Shields Complexity and Supports Re-engineered Processes 
Objects Raise the Level of Abstraction in the Software 
Solution 

30 Object development enables closer integration between 
developing applications and reengineering business pro- 
cesses. The first object-oriented language, Simula, was 
invented to enable simulation. It and other object develop- 
ment environments provide capabilities that raise the level 

35 of abstraction of the software. That is, object-oriented lan- 
guages and design techniques enable writing software in 
terms closer to the real-world business rather than the 
computer. 

Enables Improved Usability 

40 Object-oriented technology can support improved usabil- 
ity in two ways. First, objects messaging each other lends 
itself to simplified programming of advanced, direct 
manipulation or multi-media interfaces. Second, an object 
metaphor for designing the user interface may be a more 

45 desirable interaction style for some types of users such as 
knowledge workers needing flexible navigation. 
Reduces System Test Complexity and Cost 

In a few different instances, the object-oriented develop- 
ment approach has significantly reduced system test com- 

50 plexity. In all these cases the projects fell behind schedule 
due to learning curve, the complexity of custom architecture 
development, and increased effort for component and 
assembly testing. However, once core, reusable objects in 
the domain model and application framework stabilized, 

55 system testing the functionality and performance was much 
easier. For example, since less code and data knowledge was 
replicated throughout the system, global changes could often 
be made by making a change in one place. 
Component Technology May Help Improve Communica- 

60 tions with Users 

The close tie that component and object modeling enables 
between the software solution and business process may 
help software analysts and users or business analysts to 
better understand each other, reducing errors in communi- 

65 cations. This represents a significant opportunity, because 
misunderstanding user requirements has been proven to be 
the most costly type of mistake in systems development. A 
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component model further improves the understanding of the 
software design by providing a larger-grained model that is 
easier to digest. 

Lastly, communication with users is often improved by 
using scenarios which convey requirements through familiar 
business situations. 
Multiple Access Channels 

Component architectures are inherently service -oriented. 
Components provide their services through interfaces which 
consist of operations. Because components are independent 
pieces of software they can be reused by any number of 
applications. Thus, component-based architectures are well 
suited to environments that need to provide multiple appli- 
cation "personalities" or access channels. New personalities 
can be provided by creating a new user interface layer that 
reuses the existing business components. 
Managing Risk Is Key 

Component technology is still high risk, because it may 
often: have a pervasive impact on the overall -development 
approach require immature technology or tools implicitly 
involve complex functional requirements 
Component-based Development Is Not Only New Technol- 
ogy; It Is a New Approach to Software Engineering 

Component-based development should not be understood 
as just a technology decision; rather, it is a new approach for 
software engineering. Thus, it affects almost all aspects of 
development including methodology, tools, organization, 
and architecture approaches. This broad impact creates 
multiple learning curves, complicating the migration of an 
organization. Finding available skills is also difficult, 
because demand currently outweighs supply. 

Component-based systems may also require immature 
technology or tools. Many of the core development tools 
such as the programming language and environments for 
C++, Visual Basic, Java and Smalltalk are actually very 
robust. However, some of the ancillary tools such as the 
CASE tools and web development tools or technology 
architecture components such as messaging middleware 
may not be as mature. Thus, the team may face a choice of 
managing some risk exposure with a tool or library that 
simplifies development, or avoiding this tool risk but facing 
a more complex development challenge. 

Another, more subtle source of risk is the inherent func- 
tional complexity of applications often chosen for 
component-based projects. Component technology's tech- 
nical characteristics enable dynamic, functionally complex 
systems. For example, business reengineering can capitalize 
on the inherent flexibility of component-based systems. 
However, reengineering creates more dynamic functional 
requirements, thereby increasing risk. Not to mention that 
business reengineering is itself a risky venture. 

Thus, proactive risk management is an essential practice 
in development. Traditional risk management techniques 
apply to component-based projects. For example, a "top ten" 
risk list can help focus management attention. This risk 
focus must then influence the development tasks carried out 
by the team early in the project to ensure risks are addressed 
in a timely fashion. 

Architecture Is Essential to Delivering the Benefits 
Component Technology Enables Application Frameworks 
Component-based systems extend the notion of architec- 
ture beyond that in a traditional system. Much of the power 
of component-based systems is the ability to leverage appli- 
cation frameworks. Frameworks are somewhat analogous to 
program shells found in a traditional environment such as 
the INSTALL/1 online system with components like MES 
and CCP, However, this is only an approximate analogy. An 
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application framework goes beyond traditional application 
architectures to provide a greater degree of default behavior 
and flow of control in a skeleton of the application. 
For example, traditional program shells rely heavily on 

5 cut-and-paste techniques to achieve reuse. This places a 
heavier burden on the developer and exposes the structure of 
the application. With an application framework, object- 
oriented capabilities minimize or eliminate the need for 
cut-and-paste reuse. A we 11 -designed framework reduces the 

io burden on application developers by providing an architec- 
ture environment that effectively says, "Don't call us, we'll 
call you." 

There are many frameworks within the Java programming 
environment. For example, Java Security, a very important 

15 topic in new netcentric architectures, provides a Java Secu- 
rity Framework. This is a plug and play framework that 
allows developers the option of plugging in a security 
provider of their choice (DES, RSA, etc) or developing a 
custom security solution that can be called by security 

20 clients. To create a new security provider, the developer 
must only implement the required interfaces for- the frame- 
work and provide a well-known name. Once these require- 
ments are met, the component can be plugged into the 
framework. 

25 Component-based Systems Are Distinguished by a Business 
Component Model 

The presence of a Reusable Business Component Model Is 
a Key Characteristic 

3Q A component-based software architecture may have a 
domain component model shared by the application pro- 
cesses. The component model contains the core business 
components that represent the business directly in software. 
These components perform behaviors upon request by 
windows, reports, or batch process control objects. 

The presence of a component model distinguishes 
component-based systems from procedural, client/server 
systems. In a procedural approach, there is no shared busi- 
ness component model. This typically requires, for example, 

40 programs to pass data to each other in a context record. Thus, 
any changes to the data may affect many programs. The 
extent of business logic reuse is also usually less with the 
procedural approach. 

The presence of a business component model also distin- 

45 guishes a component-based architecture from that produced 
by componentware tools. Specifically, many traditional and 
even component-based tools provide data-aware controls 
that tie the user interface directly to the database. This is 
indeed a powerful technique to rapidly build simpler, less 

50 strategic applications. However, it suffers from a lack of 
smaller-grained business reuse and increased coupling 
between presentation and data. This may increase mainte- 
nance costs and miss opportunities to flexibly model com- 
plex business processes, as can be done with a component 

55 model. On the other hand, producing a reusable component 
model requires a higher level of abstraction and is therefore 
a more difficult approach. 
Component Systems Are Based on Standards 

Component-based systems are also usually distinguished 

60 by their use of one or more of the leading component 
standards, i.e. CORBA, DCOM, or JavaBeans. These stan- 
dards define the mechanisms that business components may 
use to communicate with each other. However, a system 
does not necessarily have to use one of these technologies to 

65 be considered component -based. The most important criteria 
is that the application is made up of reusable, service- 
oriented building blocks that encapsulate their functionality. 
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Component-based Systems Can Incorporate a Variety of 
Technologies 

Clients Can Select the Most Appropriate Mix of Technolo- 
gies 

Just as none of a user's client experience with objects has 
involved migration to a completely pure object solution, 
components may involve a variety of technologies. This is 
even more true for component-based systems since they 
provide the ability to integrate different technologies 
through well-defined interfaces. The ease of integration is 
very appealing to clients since it allows them to maintain 
their existing technology investments, leverage their exist- 
ing skills, and select a mix of technologies that best fit their 
tolerance for risk. 

More Diverse Skills May Be Required 

Because components can be implemented in a variety of 
programming languages on a number of platforms, it is often 
necessary to have competencies in a number of technolo- 
gies. For example, one client used Visual Basic, Smalltalk, 
C++, and COBOL for different layers of the system. The 
increasing number of technology combinations also 
increases the complexity associated with development 
activities such as testing, debugging, and configuration 
management. 

Component Can Wrap Procedural Applications 

Wrapping is a technique to integrate traditional system 
components. It applies to both the application and system 
levels. For example, a component can provide a public 
interface, encapsulating a legacy application. 

Wrapping can be effectively applied to integrate a legacy 
billing system with a large, object-oriented customer care 
system. 

At the architecture level, wrappers often provide database 
interface objects to shield the application from the database 
vendor. 

Architecture Development Must Start Early 

A Tension Exists between Scenarios and Frameworks 

As with client/server, architecture work must start early. 
As noted above, this is particularly challenging because of 
the level of application reuse in a well-designed application 
framework and domain component model. Because of this 
reuse, the framework must be heavily driven by application 
requirements, or scenarios. Yet, the architecture team must 
stay one step ahead of application development teams to 
ensure that the architecture and component model are ready 
in time to be reused. Thus, a difficult tension exists between 
scenarios and frameworks. 

The tension between scenarios and frameworks can be 
simplified to the extent that third-party or standard archi- 
tectures such as Eagle can be leveraged. In any case, the 
following guidelines should be considered, particularly for 
custom architectures: 

The architecture should be defined and prototyped, if 

necessary, early in the preliminary design 
The architecture should be complete-at the very least, the 
development architecture and overall framework, prior 
to developers actually coding; the design must be in 
place earlier when functional developers start detailed 
design; private architecture aspects may be deferred 
Time must be planned for architecture support based upon 
unforeseen scenarios, performance tuning, documenta- 
tion and developer mentoring 
Developing a custom application framework should be 
estimated as a set of tasks in addition to much of the 
traditional technology architecture development 
New Roles and Organization Strategies Must Be Introduced 
Component Projects Require Modeling Skills 

Most traditional engagements divide roles into two basic 
categories, functional and technical, or architecture. 
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Component-based development introduces a third dimen- 
sion by requiring an extensive modeling role. Early expe- 
rience has shown that the capability to draw abstractions in 
modeling a business problem or application framework is a 
5 unique skill set distinct from purely technical or functional 
skills. 

Managing the Domain Component Model Requires New 
Organization Approaches 
In addition, the extensive reuse of a core business com- 

10 ponent model requires an organization structure that man- 
ages it as a shared resource. This creates a tension between 
the needs to support consistent reuse of core components, 
and the desire to solve a business problem front-to-back. 
Experience has shown this often requires some form of 

15 matrix organization, combining vertical-based leadership 
along the lines of business functions, and horizontal-based 
leadership along the lines of architecture layers. 
Leveraging Expert Mentors and Time Are Key to Scaling the 
Learning Curve 

20 The Learning Curve Is Greater, Because it Has Multiple 
Dimensions 

Component-based development involves a longer learn- 
ing curve than comparable software technologies, because it 
has multiple dimensions. Component technology skills 

25 cover a wide range of competencies — from modeling and 
design skills to detailed programming syntax. Yet, a user 
may have good success with people scaling the learning 
curve in a reasonable amount of time. 

Programmers can expect to perform simple tasks in 2-4 

30 weeks when an architecture is in place. More complete 
implementation skills may require 8-24 weeks. Design 
skills also typically require the same amount of learning 
curve, 2—4 weeks for simple tasks and 8-24 weeks or 
slightly more for complex design problems. Usually pro- 

35 gramming should precede design experience, if possible. 
Thus, leveraging experienced component and object tech- 
nology skills is key to success. Even a few skilled compo- 
nent developers can provide significant leverage to mentor 
and support an inexperienced development team. Experi- 

40 ence has shown that at least 20% of the development team 
should have component technology or process skills at the 
outset. This represents a minimal level for large engagement 
teams with projects of one year or more duration. Smaller 
teams or shorter duration projects may typically require 

45 more. It is also extremely important to have a significant 
percentage of the team with client/server skills, to reduce 
additional learning curves such as GUI design or client/ 
server architecture development. 

Estimating and Planning Present New Management Chal- 
50 lenges 

Projects Should Allow Time for Start-up Costs and Contin- 
gencies 

There is still not enough experience with component 
technology to support rigorous, detailed metrics. One rea- 

55 sonable checkpoint for estimating an initial project is to use 
traditional techniques, and then add time to adjust for 
contingency and start-up costs such as training, learning 
curve, and architecture development. Early client engage- 
ments have demonstrated that an initial project may almost 

60 always be more expensive due to these start-up costs. 

Yet, care should be exercised in applying traditional 
estimating metrics. For example, traditional metrics often 
use number of days per window or report. Component-based 
development can result in significantly different window 

65 counts for similar functionality. 

In addition, the fixed versus variable nature of costs 
should be considered. Start-up costs are often not simply a 
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variable percentage of the project size, because roughly the larity of the software decomposition. Because the method - 

same architecture components may be required independent ologies are generic, they also typically do not address 

of size. Thus, anecdotal evidence suggests that the start-up detailed architecture or design steps, 

costs usually have a greater effect on a small project. Configuration Management and Testing Are More Complex 

Development Requires a Mix of Waterfall and Iteration 5 As noted above, the increased granularity of a 

Systems development traditionally relies on a waterfall component-based system and the variety of technologies 
model. This approach manages development in sequential associated with it complicate testing and configuration man- 
phases of activity such as analysis, design, code, and test. agement. A component-based system may often have more 
The waterfall provides control and discipline to than ten times as many components as a traditional system, 
development, particularly critical for large, mission-critical 10 While component-based systems are more granular than 
efforts. purely object-oriented systems, configuration management 

On the other hand, iteration enables proving out design is not necessary less complex. While the use of components 

assumptions in code early in the process, and testing the allows objects to be packaged into more comprehensible 

validity of code before proceeding on a wide scale. The interfaces, it also increases the number of elements that need 

information and learning gained from iteration are especially 15 to be managed. Typically, the following entities may be 

important for component-based development, because it is tracked: 

so new. As component-based architecture and methodolo- Methods 

gies mature, the need to iterate may be reduced Classes 

Significant Planning and Status Monitoring Is Necessary to „ . , , - .. , . 

Manage Iteration 20 Packages (which are often aligned with components) 

However, managing iteration on a large scale is difficult. Components 

The team can easily slip into hacking, in which design is Configurations 

simply skipped before coding. Or, a team may use iteration Applications 

as an excuse to not exercise due diligence in completing Configuration management requires a comprehensive 

tasks. Thus, a merging of waterfall and iterative principles is 25 approach of tools, procedures, and organization approaches, 

beneficial. Yet, striking a compromise between waterfall and Multiple levels of component ownership must be defined, 

iteration is not easy. Thus, significant effort must be invested The higher level of reuse requires frequent roll-outs of 

for detailed workplanning and status monitoring. updated component versions. This also typically requires the 

Incremental Development May Help Manage Scope and workplan and other status monitoring techniques to track 

Risk 30 dependencies between components at a much lower level of 

Incremental Development Partitions the System Roll-out detail. 

into Releases In addition, completing a set of processing requires many 
Perhaps the most effective way to mitigate the risks of a software components working together. Thus, testing 
large project is to simply avoid being large. Incremental involves integrating many more components. The complex- 
development addresses risk by reducing the necessary team 35 ity is magnified, because the integration work often cuts 
size and scope. "Incremental" and "iterative" development across different developers. The testing strategy must gen- 
are often used interchangeably, but they are different erally include more testing phases, each specifying a lower 
approaches. level of detail. Furthermore, automated regression testing 
Incremental development partitions the system roll-out has proven essential to address the complexity of integra- 
into successive releases. For example, the initial release of 40 tion. 

a customer system might comprise order processing, fol- Address Performance Risks Early, but Defer Application 

lowed by a subsequent release for billing, and a third release Tuning 

for collections processing. Thus, incremental development Timing when to address performance has subtle com- 

adds new functionality, while iterative development con- plexities for a component-based system. Certainly, 

tinuously refines existing functionality. 45 component-based development involves new technologies 

Incremental development avoids the complexity of a big that introduce performance risks. Prototyping architecture 

bang integration. Furthermore, although an incremental components should be initiated early to adequately address 

approach delivers less in each successive release, it can the performance risks. 

deliver higher priority portions of the system much earlier On the other hand, excessive application tuning should 
than a traditional approach, thereby recognizing business 50 not be done to the exclusion of following good design 
benefits in a shorter time frame. principles, especially if the components are built using 
Despite these benefits, incremental development is not a object technology. Experience has shown that dramatic 
panacea. Many times a big bang conversion has proven performance improvements can be made late in object- 
necessary, if the cost and risks of having parallel systems oriented development projects. Furthermore, following good 
and bridges, performing conversion, and rolling out training 55 design principles actually better enables these tuning capa- 
are high. These costs must balance those introduced by the bilities. 

delayed delivery of business benefits and the risks implied However, if more traditional approaches are used to 

by increasing scope and team size. The urgency of the implement the components, then it may be more appropriate 

business and the desire to manage development size may to tune performance throughout the development lifecycle. 

sometimes favor an incremental approach. 60 Third-Party Components Have Increasing Importance 

Commercially Available Methodologies Have a Narrow Third party components can play an important role in 

Focus software development. Today's development tools make it 

Most component-based methodologies focus primarily on easy to incorporate off-the-shelf components and customize 

analysis and design techniques. For example, less guidance them to a project's specific requirements. Thus far, off-the- 

is available for configuration management or testing. Yet, 65 shelf components have primarily consisted of user interface 

both of these aspects are more complex with component- or architecture components. One project bought third party 

based development, because of the greater level of granu- components for the user interface, device drivers, bar- 
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coding, and database drivers. This project found that it saved 
a significant amount of time, especially in areas that required 
specialized programming skills. Unlike architecture 
components, it is not likely that third-party business com- 
ponents may be available any time soon. 
Staffing, Training and Skills Development 

This chapter discusses management issues related to 
staffing, training, and skills development. 
Component-based Systems Require a Mix of Technical 
Skills 

Object Skills Are Common, But Not Required 

Components and objects are frequently considered to be 
equivalent technologies; however, they are not one in the 
same. While object-oriented systems may be developed 
using object-oriented analysis, design, and programming, a 
component-based system can be developed using a wide 
variety of languages, including procedural ones. As a result, 
the required depth of skills for a component-based project 
may depend on the blend of technologies used. For example, 
one project may require skills in COBOL, C++, and 
Smalltalk, while another may use Visual Basic exclusively. 
Because many projects are building components with 
objects, deep object-oriented skills may continue to be an 
essential ingredient in the success of a project. 
Competencies in Multiple Technologies May be Required 

Since component technologies make it possible to inte- 
grate different platforms, languages, and other technologies, 
it is often necessary to develop a broad portfolio of skills on 
a project. It is important to develop an early understanding 
of the different skills required and how they can be devel- 
oped and leveraged across a project. 
Leveraging Experienced Component Practitioners Is Key 

Leveraging experienced component technology skills is 
key to success. Even a few skilled component developers 
can provide significant leverage to mentor and support an 
inexperienced development team. 

At least 20% of the implementation team should have 
component skills 

Small teams or short projects likely require more 

Experience has shown that at least 20% of the develop- 
ment team should have object/component technology or 
process skills at the outset. These represent minimal levels 
for large engagement teams with projects of one year or 
more duration. Smaller teams or shorter duration engage- 
ments need a higher ratio of experienced component devel- 
opers. Furthermore, custom building the architecture from 
scratch may generally demand even more and deeper skills, 
unless the team has exceptionally talented individuals, 
extensive client/server experience, and ample time to scale 
the learning curve. 

It is important to note that component technology skills 
cover a wide range of competencies — from modeling and 
design skills to detailed programming syntax. Rarely may 
one individual have the necessary expertise in all these 
areas. Thus, experience has shown that it is necessary to find 
individuals that specialize in one of these areas to leverage 
across a large team. The key is obtaining the right balance 
of technology and methodology skills. 
One Engagement Used a 1:1:1 Rule to Leverage Expertise 

One large engagement found the most effective leverag- 
ing ratio was 1:1:1, comprising an experienced object 
specialist, an experienced programmer without object skills, 
and an inexperienced person. Note that this 1/3 ratio rule 
only applied to the team doing implementation. Thus, even 
though the total team size was about 200, only 40-50 were 
doing hands-on implementation, implying the need for about 
13-17 skilled people. 
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Another engagement found the best mix to be one expe- 
rienced developer to every four or five new developers. This 
project had a well-defined architecture and used Visual 
Basic to develop components. The relatively short learning 
5 curve of Visual Basic allowed this project to further leverage 
its experienced developers. 

Exercise Caution When Contracting External Component 
Specialists 

In some cases, independent contractors have proven an 
effective solution for filling gaps with specific niche skills. 
Experience has shown, however, these people may not be 
business-oriented, adapt well to the structure of a large 
engagement, nor have experience with mission-critical 
development. 

Another problem has been having to fight object religion 
15 wars. 

Managers Must Adopt New Techniques, Yet Not Forget 
Fundamentals 

It's often said that, a good manager can manage anything. 
Many management skills such as planning, monitoring 

20 status, working with end-customer expectations, and man- 
aging risk certainly apply to any domain. These blocking - 
and -tackling aspects of management must not be forgotten 
on a component -based development project. Managers may, 
at times, be intimidated by component experts, and ignore 

25 the basics of project management. 

Managing Iteration Is Difficult, but Possible 

In particular, object industry and academic gurus fre- 
quently suggest that object development and iteration simply 
cannot be managed. Their recommended approach is usually 

3Q some form of time-boxing the development, simply declar- 
ing victory whenever time is up. However, this represents a 
very unappealing approach to promising delivery of busi- 
ness benefits to clients. Fortunately, experience has shown 
that this does not have to be the case. Managing iteration, 

35 while certainly more difficult, is possible. 

However, software development managers must recog- 
nize that component technology has a pervasive impact on 
many aspects of the development process including 
estimating, planning, methodology, and technology arc hi - 

40 lecture. For example, iteration impacts many of the standard 
rules-of-thumb for work completion. And the extensive 
reuse of a common business component model requires 
more sophisticated organization strategies. 
Managers Must Invest Time In Training 

45 Thus, successful managers must be willing to invest the 
time to learn new terminology and techniques to adapt to 
these changes. Traits common to those who have success- 
fully scaled the component management learning curve 
include: 

50 Experience with client/server development and a techni- 
cal orientation 

Willingness and flexibility to learn new terminology, 

tools, and techniques 
Strong communication and people skills. 
55 Sound understanding of the system's development life- 
cycle and the risks at the various stages 
Architecture Roles Require Diverse Skills 

Complicating the search for architecture skills is the need 
to find developers who also possess the necessary commu- 
60 nications and teamwork skills. The architecture team must 
be capable of both delivering an application framework, and 
giving people appropriate mentoring and support. Many 
technology architects are simply not well equipped to handle 
the tutoring, coaching, and communications demands inher- 
es ent in component-based development. 

Avoid starting inexperienced people in architecture roles. 
There are simply too many skills to leam. Architects need to 
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have a deep knowledge of design patterns, programming 
languages, technical infrastructure, and methodologies. It is 
better to start new developers in application development 
roles where they may have the opportunity to view the 
architecture as a consumer This perspective may make them 
more effective in future architecture roles. 

While the dual role of building and supporting an archi- 
tecture exists in a traditional client/server system, it may be 
more pronounced with component technology. Component- 
based systems require a higher degree of coordination by the 
framework developers partly because more application 
developers may be inexperienced with the environment. 
However, even an experienced team requires extensive 
coordination, because a greater level of consistency is 
required. 

Developing with component technology demands more 
consistency, because an application framework and business 
or domain component model provide more reuse. In 
particular, much of the business logic may be shared by a 
common domain component model, viewed by many win- 
dows. To strive for this greater level of reuse across many 
business functions requires coordination among many 
developers. The risk is that the components may not fit 
together. 

This type of development approach requires a strong 
architecture vision that is clearly communicated and sup- 
ported through training, mentoring, and documentation. If a 
strong vision does not exist, then the components may 
inevitably not fit together into a cohesive, integrated archi- 
tecture. In addition, this strong vision must include an 
understanding of the business objectives and functions of the 
system to be effective. 

Strong architecture direction must also be accompanied 
by a positive "bedside manner". Application window devel- 
opers may often perceive a framework somewhat restrictive 
of their creativity, too limiting, or burdensome, particularly 
when bugs hold up their delivery. It's important for the 
frameworks developers to be service-oriented; and, to real- 
ize that developing a reusable component is hard work and 
requires iteration. 

Do Not Organize All the Component Skills on the Archi- 
tecture Team 

Because of the significant technical challenges often 
faced, a team may be tempted to staff all the experienced 
component developers on an architecture frameworks team. 
This strategy makes some sense. However, it should not be 
followed to the exclusion of leveraging the application or 
component modeling development team. 

Developing the functional business logic requires com- 
ponent development and methodology skills, as well. 
Staff an Engagement Team with a Mix of Backgrounds 

Staffing an engagement with deep technical skills is 
clearly a challenge. However, the engagement team should 
not overlook the importance of functional skills. Experience 
has shown that technical backgrounds may sometimes be 
over-emphasized to the detriment of functional expertise. 

It is important to remember that many roles on the team 
are more demanding functionally than technically. Inter- 
viewing users, analyzing business processes, and designing 
the user interface all do not require extensive technical 
training. Moreover, not adequately understanding and ana- 
lyzing the functional requirements are the most expensive 
mistakes. Research has shown that 70-80% of a system's 
mistakes result from misunderstood requirements. 
Component Technology Involves Multiple Learning Curves 

A component approach affects almost all aspects of the 
development lifecycle. For this reason the component learn- 
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ing curve cannot be equated with a programming learning 
curve such as 'C\ There are multiple, distinct learning 
curves that affect individuals at many different levels in the 
organization: 

5 Component and object-oriented concepts and terminology 
Object analysis and design 
Programming language 

Programming environment and other development tools 
10 ( e § > browsers, debuggers, user interface tools) 

New architectures — such as how to use the project- 
specific application framework 
Management — such as estimating and planning for work, 
and managing iteration and prototyping 
15 Educating management about the multiple learning 
curves helps manage expectations. It's also important to 
avoid equating experience with pure elapsed time. For 
example, a person may be in the implementation phase 
doing things unrelated to building their component skills 
2 q such as creating test conditions. 

Component Skills May Take Longer to Transition to the 
Client 

As a result of the many learning curves, it can take longer 
to successfully transition skills to the client. It is essential to 

25 have client participation in all areas of the project to ensure 
the transfer of skills. One of the most effective approaches 
is to have client personnel pair up with more experienced 
developers. Of course, this may be more expensive and may 
required buy-in from management. 

30 The Rate at Which Individuals Scale the Learning Curve 
Varies Widely 

Experience has shown that individuals scale the learning 
curve at very different rates. A user may have good success 
with individuals becoming productive in a reasonable 

35 amount of time. In some cases, people have learned 
extremely fast; on the other hand, a few have had consid- 
erable difficulty. 

A useful model of the expected learning curve is outlined 
by Goldberg & Rubin [3]. These results are based on their 

4Q extensive experience training personnel, primarily in the 
Smalltalk environment. Three primary levels of proficiency 
include: 

Basic — capable of doing basic assignments with adequate 
supervision, usually attained after formal training and 
45 some experience with simple assignments 

Functional — capable: of doing most assignments with a 
predictable level of productivity and minimal supervi- 
sion 

Advanced — an expert resource capable of solving very 
50 difficult or unusual problems 

They distinguish the learning curve in four different skill 
areas as shown below, measured in months: 



55 



60 



Category 


Basic 


Func 


Adv 


Analysis and Design 


4 wks 


6-8 


mos. 


18-24 mos 


Implementation 


3-4 wks 


5-6 


mos 


18-24 mos 


Frameworks Design 


16 wks 


12-24 


mos 


24-48 mos 


Management 


3-4 wks 


12-18 


mos 


24-36 mos 



The above results are reasonably consistent with a user's 
experience on client engagements. Some experience sug- 
gests that most firm personnel, on average, reach proficiency 
65 levels slightly faster than the above figures. However, a user 
may experience a much larger deviation, both positive and 
negative, than that reported above. 
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For example, some talented individuals reached a func- 
tionally competent level in implementation skills in as little 
as 8 or 10 weeks, less than half that suggested above. On the 
other hand, about 10-15% of individuals did not ever reach 
this level of expertise in a reasonable amount of time. 
Early Experience Has Identified Key Predictors of Success 

As noted above, a user may experience a reasonable 
degree of success in training personnel on engagements. 
Unfortunately, some clients have not been as successful. 

Key predictors of success can be drawn from this expe- 
rience and others. It is important to recognize that the list 
below is drawn from a very small experience base. As one's 
experience grows, the list of traits may be refined with- 
hope fully-more objective measur ability. This may be key to 
helping both a user and clients to be more successful with 
components. 

Ability to Deal with Change 

Component-based development requires a high degree of 
change. Firm personnel deal with change their entire career. 
Often, client personnel may not be as adaptive. They may 
have worked with the same structured methodology and 
COBOL for 5 or 10 years. To change their entire process can 
be a big culture shift. Individuals must have the right attitude 
and interpersonal flexibility to change. This factor may help 
explain why less experienced people have often scaled the 
learning curve faster than more seasoned developers. 

Yet, the simple fact that someone has deep COBOL 
experience does not mean that they may fail. There have 
been several examples of people on engagements who 
successfully made the transition from COBOL to Smalltalk, 
including architecture roles. However, all of these individu- 
als were highly motivated with an open mind to change. 

On the other hand, migrating to C++may be a consider- 
able challenge for people who do not have experience with 
a pointer-based language. That is, C++projects should favor 
staffing people who have minimally programmed in lan- 
guages such as C or assembly language. 
Quick Study 

Component technology involves multiple learning 
curves-people may need to learn fast. They must be moti- 
vated self-starters, capable of learning quickly on their own, 
and willing to read and perform supplemental tasks to 
improve their competencies. 
Communications Skills 

Component-based projects are very social endeavors. 
Because any given business function requires several col- 
laborating components, developers also have to collaborate 
with one another. To ensure that components integrate 
smoothly, and to achieve the desired reuse, a high degree of 
communications and teamwork is necessary. This is signifi- 
cantly different than many traditional systems where a 
system is decomposed into larger, monolithic modules. 
These modules are typically developed front-to-back by 
each developer in relative isolation. 

Creativity — Experience with Custom Systems Development 
Acomponent-based development project requires creativ- 
ity. The overall atmosphere is usually very challenging with 
fewer, concrete rules. The answer to many analysis and 
design decisions is, "it depends". Similarly, the development 
environments encourage exploration and browsing. 
Work Ethic 

Individuals must be motivated to undertake personal 
training. There often is not enough time to support all the 
training needs during normal work hours for the system to 
meet a reasonable schedule. Thus, at times, individuals must 
pursue personal study and experimentation after hours. This 
type of commitment requires enthusiastic, hard-working 
individuals. 
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Initial Training Requires Hands-on Case Studies to Be 
Effective 

Initial training requires significant upfront investment. 
Project Eagle achieved very good results with their multi- 
5 week Eagle University. Unfortunately, this represents a 
larger amount of upfront time than many engagements can 
realistically support. In addition, timing may be difficult, 
because often project team members may roll on the project 
at different times. 

Thus, many engagements may need a more flexible model 
with training time staggered in smaller chunks. For example, 
the training may be accomplished through some combina- 
tion of formal classroom training done in waves, self -study, 
case study experience with mentoring, reading, and on-the- 
job training. The key point, however, is that a significant 
15 commitment to training must be made-whether done upfront 
or spread throughout the project. 

There are several other lessons learned that can be drawn 
from the Eagle experience. Perhaps most important, training 
should be based on case studies. It should involve a signifi- 
20 cant degree of learning-by-doing including both design and 
coding exercises. Examples can be taken from the actual 
application to be built, thus reducing the perception of pure 
training investment. However, care must be taken to ensure 
that day-to-day project demands do not detract from the 
25 training. For example: 

Simple examples from well-known domains (e.g., check- 
book application) ensure that the application require- 
ments do not bog down the learning process. 
3Q People may need to be taken away from the project site, 
or firewalls created, to enable a total immersion envi- 
ronment. 

Individuals should work in teams to simulate the collabo- 
ration necessary on an engagement. 
35 If real portions of the application are used, the team 
should manage expectations so as not to confuse train- 
ing goals with producing deliverables. 
Reuse should be taught and encouraged through exercises 
that force the developer to browse. 
40 On-going Support Is Necessary for Developers to Scale the 
Learning Curve 

On-going support is necessary to help developers con- 
tinue building skills. On-going training is important because 
the entire development lifecycle is affected, to some degree, 
45 by the shift to components. An individual's first few assign- 
ments should be carefully planned to enable growing skills, 
and to identify people who demonstrate aptitude. Time must 
also be allowed for scaling the productivity learning curve, 
after initial skills are developed. This generally requires a 
50 fair degree of commitment from experienced frameworks 
developers to provide mentoring. 

A Formal Certification Process Supports On-going Skills 
Development 

Since component technology can result in many new 
55 skills and competencies, an ongoing, comprehensive skills 
assessment and certification process has proven beneficial. A 
certification process defines areas of competence and then 
critically evaluates individuals' capability and progression. 
This can extend across design and coding skills to include 
60 familiarity with portions of the architecture. Peoples* skills 
can be assessed in compulsory design and code reviews. In 
effect, this becomes a component-specific skills evaluation. 
A skills certification process helped to: 
More rigorously identify and describe competencies of 
65 what is really desired in terms of skills and compe- 
tence; and, what habits should be discouraged and 
flagged as performance problems. 
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Track peoples' growth-it encourages improvement by 

challenging people. 
Provide a more effective way to assign appropriate roles 

to people and offer up the opportunity for people to 

grow into a more challenging role as quickly as they are 

adequately prepared. 
Support more effective communications of what 

resources had which skills (e.g., through a wallchart) 

Summary 

Component-based development requires more time to 
scale the learning curve, because it has multiple dimensions. 
Component technology skills cover a wide-range of com- 
petencies including analysis, design, programming, and 
management. Thus, leveraging expert mentors and skills, 
investing in adequate training, and ensuring continued sup- 
port are all key to success. 
Team Organizations and Roles 

This chapter discusses the team organization and roles 
involved with component-based development. 
Manage the Team Size with Care 

Team size should be managed carefully. Component- 
based development involves difficult coordination overhead. 
This stems from the higher degree of reuse and greater 
modularity of the system. A greater number of common 
components are reused across business functions. In 
addition, components are smaller than traditional modules. 
Thus, more work from multiple people must integrate 
smoothly. This complicates increasing the team size. 

If a project slips off schedule, caution should be exercised 
in adding people. Brook's fundamental law states: 
Adding More People to a Late Project Makes It Later 

It is easy to underestimate the impact more people have on 
coordination and communications. Start-up costs can also be 
significant. New developers may have a learning curve. 
Even experienced developers must learn project -specific 
aspects such as the framework, business requirements, and 
team structure. These initial costs not only impact a new 
team member's productivity, they also reduce experts' avail- 
ability for mentoring others. 

Manage Expectations Regarding Developer Productivity 
Industry Gurus Have Created Unrealistic Expectations For 
the Required Team Size 

The need to manage team size must not create unrealistic 
expectations for developer productivity. High expectations 
have been fueled by many object industry experts who 
recommend a dramatically smaller team. Many have sug- 
gested that as little as 80-90% fewer people can accomplish 
an equivalent amount of work as a traditional development 
team. 

However, experience does not support these exaggerated 
claims. Initial engagements have incurred considerable start- 
up costs such as training, architecture development, and 
building reusable components. 

Some compelling evidence suggests object/component 
technology can improve productivity enough to reduce team 
size later in the software development lifecycle or for 
subsequent projects. Brooklyn Union Gas cut their mainte- 
nance staff in half and still accomplished as much or more 
work. Other firm experience has shown object technology 
reduced system lest effort, enabling a smaller team. Large 
engagements have also realized benefits of reuse, signifi- 
cantly reducing development time for windows later in 
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development. However, none of these experiences reported 
an order of magnitude reduction in team size. 
Use Components As Work Packages 
Components Can Define Work Packages 

5 Perhaps the most effective way to mitigate the risks of a 
large project is to simply avoid being large. Partitioning a 
project into smaller sub-systems is one way to reduce size. 
Component-based development is particularly well-suited to 
partitioning the development effort because the constituent 

3Q components can map directly to team responsibilities. This 
simplifies division of responsibility and roles, because soft- 
ware and team organizations can mirror each other. 

For example, FIG. 44 shows a high level picture of 
application component interaction for an Order Entry sys- 
tem. The boxes represent the application components of an 
application being developed. Orders are fulfilled by inter- 
action with the Product, Customer, and Warehouse Appli- 
cation Components. These software application components 
can then serve to define the structure of teams and their 
collaborations with each other, 

20 

Keep in mind, however, the benefits of this partitioning 
approach may be influenced by the degree with which these 
components interact. Thus, determining the appropriate 
granularity of the components is a key, strategic design 

25 decision. 

Greater Specialization of Roles Is Necessary 

Two recent engagements involved very large teams, in 
one case peaking at over 200 people working with object- 
oriented technology. In both cases, the engagement teams 

3Q leveraged expertise in a manner somewhat similar to a 
traditional engagement. There were, however, important 
differences in scaling object-oriented development to such a 
large size. 

One important distinction is the categories of expertise to 
35 be leveraged. For a traditional engagement, most developers 
tend to be divided in two basic categories — functional or 
technical. These two dimensions represent the primary types 
of leveraged expertise. That is, guidance is provided by 
functional and technical experts. 
4Q Component Development Requires Functional, Technical, 
and Modeling Competencies 

A component-based project adds a third dimension — 
modeling. The skill set to model and represent behaviors and 
relationships in components and objects is a distinct, com- 
45 plimentary skill set to functional and technical skills. Thus, 
most projects find that they need a third type of expert — e.g., 
a component/object modeling architect(s), to provide direc- 
tion. 

Four primary online development roles may be defined: 
5Q window team members developed the window-specific 
functionality. Their role was biased towards consuming 
rather than providing common object behaviors, 
although there was some degree of the latter, 
object model team members developed complex behav- 
5S iors in the common object model; they also performed 
quality and consistency reviews for object model 
behaviors implemented by window developers, 
frameworks team members developed the overall archi- 
tecture mechanisms, providing structure and default 
60 behavior for the entire application. 

server team members developed common data access and 

service routines on the server. 
Architecture roles must be defined to support this greater 
degree of specialization. One engagement used the follow- 
65 ing partitioning strategy: 

Functional architect-responsible for resolving decisions 
for what the system should do. This person is ideally a 
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user with a solid understanding of systems, or a systems The organization Structure Must Enable Specialization and 

person with a good understanding of, and relationship Collaboration 

with, the users. Component development requires a more sophisticated 

Technology architect-responsible for delivering the organization structure to support the increased specialization 

platform, systems software, and middleware infrastruc- 5 and collaboration of roles. Specialization is generally more 

ture to support execution, development, and operations important because more is being custom created-and less of 

architectures tne answer * s codified as a proven solution. As noted above, 

1T . t - . ui e j „ well-defined roles are also important to ensure reusable 

User interface architect-responsible for setting direction onen ts fit to ether 

of the user interface metaphor, layout standards, and A f . j r 4 . i . 

10 At the same time, the structure must enable adequate 

integrated performance support lira), n u *• * * u t • i- . 

& r rr \ / collaboration of team members. Too many specialists may 

Application frameworks architect-responsible for result in an organization that requires extensive coordination 

designing, delivering, and supporting the application t0 delivef anything.^ g<> a completed window. The orga- 

framework that provides the overall structure, or nization must then strike a balance between "vertical" 

template, of the application. 15 part itioning by function and "horizontal" partitioning by 

Object model architect-responsible for identifying and architecture layer. This is a classic management problem at 

resolving modeling issues necessary to achieve a high an enterprise or project level. 

degree of business reuse and modeling consistency. Vertical Partitioning by Business Function Better Supports 

Note that the last two roles are especially unique to Collaboration 

object-oriented and component -based systems. This means 2 o FIG. 45 illustrates a traditional organization structure 

these architects have a learning curve to simply understand including an activities component 4502, a credit/collections 

what their role means in the organization. Furthermore, the component 4504, a billing component 4506, and a finance 

architecture roles require the deepest technical skills and component 4510. This traditional organization for most 

should be staffed with the more experienced resources on the projects is vertically organized based upon business function 

project. 25 with a technology architecture team. In this organization 

One must be very careful in ensuring that application model, there would be one or more developers that are 

frameworks are not "over-architected". Experience has responsible for building a business function end to end. This 

shown that many frameworks fall by the way-side for the works well for the following reasons: 

simple reason that they were not built closely enough in aligns well with the business process and software decom- 

conjunction with the application development. They become 30 position enables clear work direction— i.e., complete a 

too theoretical, complicated and over-engineered making window or report, front-to-back 

them performance bottlenecks and obstacles to simplifying ensures that complete functions work in an integrated, 

the application architecture. It has been found that frame- end-to-end fashion 

works should "fall out" of the application domain as can- teams beUer ah tQ Hcation releases 

didates become obvious. Experienced developers that work 35 However, there are several potential shortcomings with 

closely with the application can quickly identify repetitive mis h for an object-oriented system: 

constructs and abstract useful frameworks from this context. m& f orce d eve i 0 ers to learn multi le as ects of the 

Data and Object Model Architects Must Clearly Define ma 7 ° rce , , ^ . . f A 

™ * d i framework (e.g., user interface and persistence 

eir o es services) which does not enable as much specialization 

One issue that must be resolved early on is the relation- 40 Q ^ 

ship between the role of the data architect and the object , * ■ * ^ f . • 

*j , i_ ** j t j •* * 1 j 1 * • * does not easily support consistency and reuse of business 

model architect. In traditional development environments . j rr j 

losic 

data architects produce deliverables such as Entity Relation- 6 c e 

ship diagrams. Since an Object Model is a superset of an E/R does not readil y enable cross-function leverage of exper- 

diagram, it is important to avoid treating the two as separate 45 „ . tise A , . „ 

entities because this can lead to development teams working Horizontal Partitioning by Architecture Belter Supports Spe- 

from two separate schemas. Viewing the object model as the cialization . , , 

object and data schema is very helpful in solving perfor- Seve u ral object-oriented engagements have tried an alter- 

mance problems later and in promoting an overall under- n * t,ve horizontal or architecture-based, organization. FIG. 

standing of the information schema of the system. 50 46 f™!" f ^os™™ of a »»nzonHl organization 

One strategy that has been shown to work is to include the model 4 K 6 , 00 ; In < b,s mod f • one or „ more dev e'°P ers are 

senior data modelers in the object modeling team and give «spon S1 ble for a horizontal layer of the system. Teams may 

them appropriate object modeling training for their roles. ^ organized around layers such as technology architecture, 

t, . 11 t 1 • r.i. i_ ■ * j 1 * l *u frameworks, user interface, component/object model, or 

This allows a natural migration of the object model to be the «^ »*. v, w F j , 

logical schema for the database model. However, this must 55 ™ . * , «- 1 . * „ j 

be carefully managed so that good object model principles ^ a PP roach offered the ™ Q ™S advantages: 

are not violated by a strong-minded data modeler who has ah g» ed wth the ob J ect architecture 

not transitioned through the paradigm shift. enabled cross-function consistency and reuse of business 

Greater Collaboration between Roles Is Necessary logic 

Another distinction is the necessary coordination of roles 60 supported developing and leveraging specialized exper- 

due to the impact reuse has on the organization. In a tise 

traditional architecture, modules tend to be larger front-to- However, the following drawbacks were experienced: 

back slices of functionality. Reuse is primarily confined to over-the-wall problems in coordinating hand-offs of work 

technical services. Thus, functional developers can work amongst multiple developers 

independently, relatively speaking. The greater degree of 65 providing work direction to people became more compli- 

reuse in a component architecture, on the other hand, cated since they were poorly aligned with the business 

requires much more coordination of effort. problem 
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managing completion of business functions becomes Workcell alignment may be influenced by the needs of the 

□early impossible client. If the client's objective is to develop a highly 

A Workcell Organization Combines the Two Approaches reusable business component model, then it may be 

FIG. 47 illustrates a workcell organization approach appropriate to have a single team focused on develop- 

including an activities component 4702, a credit/collections 5 mg lne component model On the hand, if the client is 

component 4704, a billing component 4706, and a finance most concerned about delivering business 

component 4710. This approach combines the two previous functionality, workceUs should be aligned by business 

approaches into a workcell. The primary orientation can be function 

aligned either way, but a functional orientation seems more The Organization Must Support Informal Structures 

natural for a business apphcaUon. A cell is comprised of a 1Q ^ formal ^ the ject must enable 

complete set of specialized skills such as functional analyst, ^ . . c . ° . t . ^ * j i 

r j * r .. . .... . « extensive informaJ communications. Component develop- 

obiect modeler, application architect, and even user. Cross- . . . . .. , ^ r t . r , 

. J . ,. , rtf ., . . ,. 4 . ment requires a tighter coupling between functional and 

cell architects then provide specialized direction for a par- . , . 7 a • u r o ... . . , , 

. . t technical design, because more commonality is incorporated 

ticular role. ■ . «u u-r „ ^JL e \ 

. , . i !• i • t into the architecture as common services. I nus, tew lmpor- 

This approach, while adding complexity to the orgamza- , . . j • . u M a i i u *u- *u 

V . , , c_ ti . , 15 tant decisions can be made solely by one group within the 

tion structure, has been used successfully on a number of meet 

engagements, and has been shown to combine the benefits of ^ ement sewM different strate . 

L "W™" ■ °f. C0 " rse ' 3 , dra 7 back 15 S ' mP L y ? to ensure effective communications across organiza- 

added level of organizational complexity — e.g., individuals ^onal boundaries' 

at times taking direction from two different people. ^ n ' 

Additional Effort Is Needed to Ensure Consistency Across 20 cross-cell weekly integration meetings were used to dis- 

Workcells anc * reso ^ vc low-level issues of global concern 

Additional effort is needed to ensure that each workcell temporary, cross-cell teams were formed to address many 

develops application components in a consistent manner. It special issues — e.g., integration with an external 

is important to define development standards and entry and 25 system, an approach to handle addresses, etc. 

exit criteria for all workcells. In addition, it can be useful to temporary scout teams were formed to pilot the approach 

have a single person or group perform design reviews across for a global change before rolling out to the entire 

the project. team — e.g., the migration approach for moving sub- 

A workceirs architect or frameworks developer can also systems into system test, 

help application developers better understand the architec- 3Q It's also important to consider the importance of informal 

ture and use it consistently. Furthermore, the workcell sharing of information when many developers are undergo- 

architect serves as a good channel to feed new ing training or there are global architecture changes under- 

requirements — based on the application developers way. Geographic splits of a team can cause special problems, 

experiences — back to the architecture team. Roles are Changed for Personnel at Multiple Levels 

Management May Need to Plan for at Least One Major ^ There often is not a direct mapping to the traditional roles 

Reorganization that individuals expect. Analysts and Consultants may be 

The most effective approach depends on the team size, given tasks with less creative freedom than they expect. For 

relative experience, and even the phase of the project. The example, an Analyst role may involve less custom coding 

dependence on development phase implies that management and more reusing, assembling, and testing of components, 

may need to plan for at least one reorganization. 4Q Design tasks for a new Consultant may also seem overly 

Unfortunately, re-organizations create significant team restrictive, because the challenge is to do things in a much 

disruption, which must be considered. more consistent, standard manner as dictated by the frame- 

Workcell Organization May Be Influenced by Other Factors work. 

Some additional guidelines include the following: On the other hand, because everything is often so new to 

Larger teams generally need to favor increased 45 the entire project team, in some ways everyone is starting 

specialization, because they may almost always have a together from scratch. Thus, in a few cases, very talented 

higher proportion of inexperienced developers. Thus, Analysts with prior component experience have assumed 

the specialized model supports developing areas of lead technical design roles. 

competency. Traditional Hand-offs Between Designer and Coder Are 

Early in an engagement more specialization may be 50 Problematic 

required as an infrastructure of common components The way roles work together is also different. For 

and frameworks is constructed. example, because of the iteration and coupling required 

Once components are stable and integration of function- between design and code, hand-offs from designer to pro- 

ality is more important, then a collaborative, grammer generally do not work well. One scenario used to 

functionally-aligned or workcell organization may 55 leverage skills involved a lead designer creating the design, 

make sense. prototyping the solution, and stubbing-out methods with 

The higher degree of custom development required in the comments. The details were then flushed out by a junior 

architecture, the more specialization of skills is neces- developer. Leveraging by review and mentoring has also 

sary; likewise, the more stable the architecture, the less ^ eeD ^ C V" 

important is specialization in favor of supporting col- 60 o 

laboration ™ 

Complex, non-standard problems that cut across domains Crafting an organization structure for a component-based 

lend themselves to increased collaboration. On the project involves balancing many complex factors. The most 

other hand, more standardized problems can be solved effective approach may depend upon the size and skill set of 

with the specialized model. This experience is also 65 the team, the architecture structure and stability, and even 

consistent with management research of macro- the type of the application. Some additional considerations 

organizations for an enterprise. include: 
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Regardless of the chosen organization, care must be takeQ Distinguish between the Macro and Micro Process in the 

to ensure walls do not build up between teams Workplao 

People's behavior may be influenced by the organization; Bo,h tne waterfall and iteration have pros and cons. A 

that is, research has shown that the organization model hybrid capitalizes on the advantages of both If they are 

may be reflected in the software architecture. For 5 merged, one or the other must inevitably dominate the 

example, one engagement experience may shown that sUuctureof the high- evel project plan That is, the plan must 

• j • -J | ° t * l * t . . . start somewhere — either by defining iterations or waterfall- 

individuals may allocate behaviors to inappropriate iik e phases of completion 

components to avoid having to collaborate with other ^ examp , e> d( £ ning iterations of me sys , em of sub . 

developers , system would result in high-level project phases such as: 

Workcells combine the benefits of horizontally and ver- 10 g fSt ^ji^a version 

tically aligned organization structures, and have been used refiQed versioQ 

successfully on a number of engagements. « i i j i • 

. . w . ^ i . final, released working version 

Planning and Managing Development In a mQre traditional waterfall structure would 

This section discusses strategies for managing a resu i t in high-level project phases such as: 

component-based development process. Two alternative 35 requirements definition 

development strategies are: preliminary design 

Waterfall approach detailed design and/or coding 

Iterative approach testing 

Much of the one's experience may be with large, mission- 2 q A macro plan reflects the high-level development phases 

critical projects. Moreover, large projects introduce The micro plan shows the tasks of a specific phase or team, 

additional, inherent complexity. Therefore, these issues may Distinguishing between a macro and a micro process 

be discussed primarily from a large project perspective. provides a practical compromise. The pure, traditional 

A Tension Exists between the Waterfall and Iterative Devel- waterfall has no distinction. There, the entire workplan and 

opment Models 25 accompanying development approach sequence analyzing 

The Waterfall is the Traditional Approach to Managing everything, then designing everything, then coding and 

Software Development testing everything, with no overlap. The same uniformity 

Systems development traditionally relies on a waterfall between macro and micro processes applies to a pure 

model. This approach manages development in sequential iterative model. In this case, the workplan reflects multiple 

phases of activity such as analysis, design, code, and test. 30 iterations of the entire application. However, in either case, 

The waterfall model provides a controlled, orderly process such extremism is not necessary. Instead, a plan can merge 

for developing a system. Work is sequenced to ensure that the two approaches by distinguishing between the: 

the design addresses the correct requirements, implementa- macro, high-level plan, and 

tion is based on upfront design, and system testing verifies micro, phase or team-specific plan, 

and validates thoroughly unit tested components. 35 In summary, an exclusively waterfall or wholly iterative 

Despite these benefits, the waterfall model introduces model are, independently, too simple. A balance is required, 

potential problems. For example, Distinguishing between the macro and micro process gives 

Requirements may be difficult for the user to understand management the intellectual freedom to craft a workplan 

without prototyping the user interface or functionality tnat reflects a mix of the two styles. The downside is that this 

The design team may not be prepared to specify an 40 introduces significantly more effort and complexity in the 

effective design without gaining implementation expe- £i aD ^ m ^ P r °f ess - , _o n 

B &r h The Macro Process for Large Projects Should Be Waterfall 

nence ¥ w & j 

. . J In Nature 

A team may not be positioned to generate reusable Man s ^ Averse t0 iteration, because It Expects 

components for itself, unless a team works ahead to 45 j^^q^ j pso Facto 

construct an architecture or component model during The lajd QUt ^ alteraatives for com . 

tne design pnase bining the macro and micro process. For large, custom 

Iteration Helps a Team Address Risks and Gain Experience development projects, experience has shown that defining 

Because of the above shortcomings, much of the 00 and the macro process along the lines of a waterfall structure is 

component community recommends some variation of itera- 50 m0 st effective. Client and firm project management are 

tive development, in which analysis, design, and coding typically uncomfortable with defining milestones and esti- 

activities overlap to some degree. A theme in these varia- mating work with iterations. The common statement is, 

tions is the need to address risk by proceeding further in «How do I know when I finished the current iteration?" This 

development sooner. Both the gained information and expe- concern is valid — on a large-scale, "complete" can be dif- 

rience can influence the approach taken in the current phase. 55 ficult to define. In addition, most managers have trouble 

However, iteration also has drawbacks. The team may slip embracing a process that expects and even allows mistakes 

into hacking, by simply skipping design before coding. Or, 0 n such a large scale. 

a team may use iteration as an excuse to not exercise due Iteration Does Not Scale Well Due to Communications 

diligence in completing tasks. Defining and estimating mile- Overhead 

stones is also hard. 60 Aside from these psychological considerations, large 

A Project Must Weigh the Tradeoffs between Waterfall and projects introduce significant risks due to the complexity of 

Iterative Models coordination. A large team has a much greater inertia, 

Thus, a tension exists. The waterfall promotes discipline because of the time delay and errors introduced in human 

and control in the development process. In contrast, iteration communications. Any change takes much greater effort and 

proves out assumptions, gains advance experience, and 65 time to implement. Correspondingly, once made, changes 

addresses risks. Balancing these conflicting goals is difficult are more difficult to reverse. Greater reliance on documen- 

on a large scale. tation is often necessary to avoid miscommunications. 
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Many decisions must then be considered from the vantage 
point of their ease of communication. This complicates 
iteration. For example, if analysis, design, and code overlap 
extensively, then by definition, requirements and design 
change later in the process. Communicating wide -scale 
changes late in development can be inefficient, wreaking 
havoc on existing code. Thus, iteration does not scale well 
to the macro level, because of communications overhead. 

It's important to re-state, however, that a pure waterfall 
introduces many problems for component development due 
to its intrinsic reuse and newness. Thus, many of the lessons 
below emphasize variations of iteration and how they can be 
merged with a waterfall approach. 

Incremental Development May Help Manage Scope and 
Risk 

Incremental Development Partitions the System Roll-out 
into Releases 

Perhaps the most effective way to mitigate the risks of a 
large project is to simply avoid being large. Incremental 
development addresses risk by reducing the necessary team 
size and scope. "Incremental 1 ' and "iterative" development 
are often used interchangeably, but they are different 
approaches. 

Incremental development partitions the system roll-out 
into successive releases. For example, the initial release of 
a customer system might comprise order processing,, fol- 
lowed by a subsequent release for billing, and a third release 
for collections processing. Thus, incremental development 
adds new functionality, while iterative development con- 
tinuously refines existing functionality. 

Incremental development is often more palatable to man- 
agers than iterative development, because there is no explicit 
notion of repetition. Yet, the desirable benefits of iteration 
are often realized. For example, releasing consecutive ver- 
sions of the system creates the opportunity, and often the 
requirement, to refine the initial release. The early imple- 
mentation experience can also provide important productiv- 
ity benefits for subsequent releases. This experience may 
also help drive out technical requirements for future 
releases, improving the analysis and design process. 

Incremental development avoids the complexity of a big 
bang integration. Furthermore, although an incremental 
approach delivers less in each successive release, it can 
deliver higher priority portions of the system much earlier 
than a traditional approach, thereby recognizing business 
benefits in a shorter time frame. 

Despite these benefits, incremental development is not a 
panacea. Many times a big bang conversion has proven 
necessary, if the cost and risks of having parallel systems 
and bridges, performing conversion, and rolling out training 
are high. These costs must balance those introduced by the 
delayed delivery of business benefits and the risks implied 
by increasing scope and team size. The urgency of the 
business and the desire to manage development size may 
sometimes favor an incremental approach. 
Incremental Development Can Also Apply to a Single 
Development Release 

Even when incremental development does not prove 
feasible for entire application releases, the approach can be 
effective on a smaller scale. For example, the development 
and release of a single application may require extensive 
integration of diverse behaviors in a reusable domain com- 
ponent model. The domain components must be put in place 
early to allow reuse; then, behaviors are incrementally added 
as the business use cases are analyzed and designed. As in 
the previous case, iteration naturally occurs; but, again, 
incremental proves to be a more acceptable metaphor. 
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Enable Top Down and Bottom Up Development 
Different Categories of Tasks Should Proceed at Different 
Rates 

Whether applying a more waterfall, iterative, or incre- 
5 mental process, the dependencies between tasks require 
careful consideration. Different categories of tasks need to 
proceed from problem-definition through solution at differ- 
ent rates. 

FIG. 48 illustrates the Enterprise Information Architecture 
10 (EIA) model 4800. This model adapts to component 
terminology, with the relatively minor change in layer five 
from data architecture to domain component model. 
Both Top-down and Bottom -up Models Are Necessary 
This model incorporates the idea of simultaneous top- 
is down and bottom-up development. Much development 
effort may follow a relatively top-down, sequential 
approach. This includes analyzing and designing: the busi- 
ness environment and processes, domain model, and then 
application. Concurrently, an architecture effort proceeds 
20 bottom-up. This builds: the technology architecture of plat- 
form system software, hardware and infrastructure services; 
and then application architecture, or frameworks. Top-down 
and bottom-up efforts then conceptually meet in the middle, 
integrating the application framework with the application, 
25 Both the Architecture and Component Model Lead Appli- 
cation Development 

The need to start architecture implementation early is 
well-understood for traditional or component-based client/ 
server development. What is different with component- 
30 based development, however, is the need for the component 
model to lead the application and user interface develop- 
ment. 

Starting the component model early is essential to 
enabling reuse of a consistent, cross-functional set of busi- 

35 ness components. These core domain components must be 
defined early, at least in preliminary form. Otherwise, the 
simultaneous integration of functionality from many win- 
dows or reports would be extremely chaotic. In addition, 
developers may implement business logic in the user inter- 

40 face layer, rather than in the business components where it 
can be reused. Furthermore, early design of the component 
model before user interface logic improves the odds of 
creating a pure component model, decoupled from the 
interface. 

45 Design Efforts Should Focus on Component Interfaces 
Interfaces are the contracts for the services that a com- 
ponent provides. Clients of a component are concerned with 
what the interface specifies, not how it is performed. It is the 
interface provider that is concerned with the implementa- 

50 tion. By correctly defining interfaces during design, it is 
becomes possible to independently develop components. 
When interfaces are changed, component assembly becomes 
much more difficult and rework is often required. Thus, 
design efforts should pay additional attention to the com- 

55 pleteness of interface specifications. 

Architecture Development Must Start Early 

A Tension Exists between Use Cases and Frameworks 

As with client/server, architecture work must start early. 
As noted above, this is particularly challenging because of 

60 the level of application reuse in a well-designed application 
framework and domain component model. Because of this 
reuse, the framework must be heavily driven by application 
requirements, or use cases. Yet, the architecture team must 
stay one step ahead of application development teams to 

65 ensure that the architecture and component model are ready 
in time to be reused. Thus, a difficult tension exists between 
use cases and frameworks. 
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The tension between use cases and frameworks can be 
simplified to the extent that third-party or standard archi- 
tectures such as Eagle can be leveraged. In addition, expe- 
rienced architects may bring their knowledge of which 
services are common across applications and can be 
addressed earlier than application-specific architecture ser- 
vices. In any case, the following guidelines should be 
considered, particularly for custom architectures: 
The architecture should be defined and prototyped, if 

necessary, early in the preliminary design 
The architecture should be complete — at the very least, 
the development architecture and overall framework, 
prior to developers actually coding; the design must be 
in place earlier when functional developers start 
detailed design; private architecture aspects* may be 
deferred 

Time must be planned for architecture support based upon 
unforeseen use cases, performance tuning, documenta- 
tion and developer mentoring 
Developing a custom application framework should be 
estimated as a set of tasks in addition to much of the 
traditional technology architecture development 
Failure to Develop the Architecture Early May Reduce its 
Efficacy 

If the architecture is not completed ahead of the 
application, developers may have the tendency to build 
architecture services in the application layer. Clearly, this 
may lead to diminished reusability and more difficult main- 
tenance. By defining the architecture services early and 
communicating them clearly to the application teams, these 
problems can be avoided. 

A related problem with object architecture and frame- 
works is that the line between the application and architec- 
ture can become blurred. These architectures may provide so 
much common functionality that it is difficult for teams to 
distinguish who is responsible for what. For example, it may 
not be clear that a function should be provided by the 
application architecture team, technology architecture team, 
or application team. This problem can be resolved by better 
communication and coordination across teams. Workcells 
are one approach that has proven effective in this area. 
Component-based Development Requires More Granular 
Milestones 

The Macro Process Uses Traditional Milestones 

The milestones used to track the macro process generally 
remain the same as for traditional systems lifecycles. Project 
management may still be interested in monitoring the 
progress of high-level milestones such as the start and end 
of design, or the start and end of construction. 
The Micro Process May Use More Granular Milestones 

On the other hand, the micro process may have more 
granular milestones than traditional systems. Whereas a 
business function in a traditional system may be composed 
of single front-to-back module, a component-based system 
may provide the business function using several collaborat- 
ing components. Thus, component-based systems inherently 
have more work objects to track. While the increasing 
number of work objects may seem to be a management 
burden, it can provide a more fine-grained reading on the 
development process. 

Another difference from traditional systems is that mile- 
stones may be more oriented around elements of the systems 
(windows, business components, and architecture 
components), rather than business functions. Furthermore, 
some types of milestones may be more important than 
others. For example, if there is a significant amount of 
functionality in the business components, then there may be 
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more milestones associated with the business components 
than with the user interface. 

The Micro Process Should Vary with the Type of Develop- 
ment Role 

5 The Micro Process Must Compliment the Macro Process 
Assuming a waterfall-like macro process, as described 
above, the challenge of the micro process is incorporating an 
effective level of iteration into this management framework. 
Different roles for team members require different devel- 
0 opment methodologies. For example, possible roles are: 
Application developer — responsible for implementing a 
particular business function, such as accepting bill 
payment. This focuses on the application-specific 
design and implementation tasks such as: working with 
a user to define requirements or use cases, designing the 
15 user interface, and implementing application function- 
ality. 

Component Model developer — builds, refines, and sup- 
ports the core, reusable business components in the 
application. 

20 Frameworks developer — responsible for the application 
and technology architecture that provide common ser- 
vices and control logic for the application. 
These roles do not necessarily correspond directly to 
organization assignments. Whether these roles formalize as 
25 teams, identities within a workcell, or possibly different hats 
a single person wears is an organization decision that 
depends on the project size, individual skill sets, and other 
factors. 

Within the Micro Process, More Parallelism Can Be 
30 Achieved 

At the micro-level components make it more reasonable 
to execute more development tasks in parallel. Components 
enable this by providing more discrete work objects that are 
more clearly separated by their interfaces. Because inter- 

35 faces are the contracts through which components interact, 
the internals of a component can be developed indepen- 
dently as long as the interfaces are respected. 
Dependencies on Shared Components Need to Be Managed 
On the other hand, since some components may be reused 

40 throughout the application, it is a good idea to start them 
earlier to provide a so fid base for the rest of the system. 
Thus, a greater dependency on certain reusable components 
may require additional planning effort to correctly sequence 
the work. 

45 Application Developers Can Follow a Relatively Formal, 
Sequential Process 

A significant portion of application development can 
execute in a sequential manner. This excludes the develop- 
ment and maintenance of the core component model and 

50 application frameworks discussed below. For the application 
developer driving out requirements, design, and implemen- 
tation of window functionality, development can proceed 
very similar to that of a traditional, client/server GUI 
project. Particularly early in development, many aspects of 

55 the methodology can be very similar such as CAR (Control 
Action Response) diagrams. 

During implementation, detailed design and coding steps 
may overlap. However, the rules and guidelines for sequenc- 
ing these should be spelled out in rigorous detail. Note that 

60 this does not imply iteration per se, although that may be a 
desirable side-effect if controlled. Rather, this approach 
merely suggests tactically interspersing the design and code 
activities, particularly to aid in- experienced developers in 
transitioning from design to code. 

65 Define Concrete Milestones with Short Intervals 

An important difference in managing efforts with this type 
of overlap is the need to define much more concrete mile- 
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stones with shorter intervals. This is necessary because a proof-of-concept prototype 

detailed design or coding phase deQnition loses meaning if pilot process prototype 

they overlap extensively. Milestones represent more These categories may be addressed with throw-away 

concrete, visible accomplishments, such as: prototypes, initial working models which are later refined, or 

all basic layout and behaviors designed; complex behav- 5 some combination Use of "prototype" below generally 

iors identified, but not completely designed reters to either style. 

, User Interface Prototypes Help Users Understand Require - 

view and application model integrate with domain model me nts 

window opens User interface prototypes address the difficulty that users 

data access from server coded and tested 10 have in defining requirements without implementation 

a. ii -i^j i • r • , - „ , examples. This phenomenon is analogous to the Heisenberg 

full detailed design of special processing or complex TT il • . n • ■ i -m.* i c j t_ • 

behaviors r r & Uncertainty Pnnciple. This law of modem physics states that 

e 1 the simple act of trying to observe the position or velocity of 

complex behaviors coded and tested electrons affects the result itself. Likewise, users' percep- 

Incrementally Add Behaviors to the Reusable Component tions of their requirements may be changed, sometimes 

Model 15 dramatically, by observing examples of the potential solu- 

A previous point emphasized starting the component tion. In many cases, these prototypes have been used as a 

model development early, because many of these compo- standard design deliverable with repeated review and refine - 

nents are reused in many business functions. Thus, their ment with the user. 

preliminary structure must be available before multiple An important consideration, however, is scope control, 

windows require their use. This implies that many different 20 There is a very complex management problem when itera- 

behaviors may need to be continuously integrated into these tion * used to drive out requirements with users. Experience 

components over and over. The component model nas shown that users may assume that exploring an alter- 

development, then, is very much event-driven like a factory. native implies that the functionality may be implemented. 

Incremental Is a Good Term for Continuous Integration of Thus, *° mQ change control procedures need to be defined 

Behaviors in the Component Model 25 and managed, even if they do incorporate some flexibility to 

The salient feature of this development style is that incorporate enhancements, 

behaviors are incrementally added to the reusable compo- Performance Prototypes Address Global Architecture Issues 

nent model throughout the development. Iteration and Performance prototypes primarily address technology 

refinement often occur naturally in this process. However, architecture questions. For example, the architecture team 

incremental proves to be a more acceptable term for man- 30 ma y need t0 decide earl y on whether to use messaging, 

age ment. remote procedure calls, or shipped SQL statements for 

When developing in this fashion, tracking status is diffi- distribution services between client and server. A prototype 

cult. Management traditionally tracks status by number of * often the onl y wa X t0 identif y the most effective solution, 

windows or reports complete. Yet, in this style of Proof-of-concept Prototypes Address Complexity 

development, the windows complete may fluctuate dramati- 35 Proof-of-concept prototypes address areas of significant 

cally. Some windows may not achieve completion until very technical or functional complexity. In the most extreme case, 

late in the project, when the component model stabilizes. the team ma y uncertain as to whether they can even 

Yet, many behaviors may indeed have been completed. This develop the logic within the specified quality parameters. Or, 

creates an illusion that the project is further behind than il ma y be 100 difficult to desi S n a solution upfront, because 

reality. More sophisticated status tracking is therefore 40 of a mix of technical, functional, and maintainability issues, 

needed. m 51100 cases > the team may need to implement alternatives 

Iterate to Address Risks or High Degrees of Uncertainty £° r evaluau on. 

Prototypes "Buy Information" that Reduces Risk Process Polypes Provide Experience for the Team 

Iteration is required to address risks involving a high Pllot P rocess Prototypes are ^sed primarily for the team to 

degree of unknown. These risks tend to increase with 45 8"° ^perience. TT^ey typically use a front-to-back slice of 

component-based development, primarily because of its lh ? W^nn. This is similar to increment^ .development, 

novelty. Thus, the need to iterate is often less intrinsic to * hic , h *Y° lu f™ l ° * T 

component-based development and more related to chal- ^nctionality^Such learning benefits are not unique to pilot 

lenges naturally resulting from unfamiliarity. What is now Prototypes. The distinction of a pilot prototype, however, is 

"traditional" client/server development faced similar diffi- 50 * at f inm S «P«™ce is the primary purpose of the effort, 

culties years ago. The learnm S ma y focus on technology, business function, or 

In some cases, this unknown requires experimentation. JJ? 61 ^ 0 ^ 0 !^^*. _ 4 . „, . , „ , „ . 

~ , 4 • l .u i* • . . Confine Highly Iterative Tasks to Experienced Framework 

For example, a throw-away prototype has the explicit intent n I 

to "buy information" for reducing risk. Prototypes are a „ 1t J. , , , , . , 

. / i * i ■* * * 55 Iteration demands very experienced developers, to under- 
special case of iteration involving less commitment to . . . . - J , \. ™ t . \, ' 
*, , * , , . stand the catena for completion. Thus, tasks that require a 
salvage the work. Whether the prototype is salvaged or not . . - % * , t \ . . 4 t M 
. , , „ . t . • i ■ 1.1. very high degree of iteration, such as technical prototypes or 
becomes less relevant, because the primary value is in the A % 7 c ui . u u u i j . 

• fY_ ot - . t • . I iUa ^/ J development of reusable components, should be confined to 

information obtained in the process. ,f t - . .*\ . 9 ™ . ,. . 

0 . . « r • i ■ vt a small team or experienced developers. These individuals 

Several Afferent categories of nsk requtre iteration. None fi0 ^ ^ £ arcbitecture fra F meworks team . 

1 f T K UmqUe oom P° neDt : based deve opment But Qne ig (Q s , aff ^ frameworks team ^ , he 

they tend to be more tmportant with component technology mQst rienced nent deV elopers, comprising about 

because again, so much of the underlying technology and 5 _ 10% of ^ ^ ^ ^ ^ ^ 

methodology are new. Some of the types of prototypes are al]ow ^ mQst skmed devel t0 iterate more _ research 

(Tnese are sim.lar to other defin.tions): fi5 faas shown tha( vgry experienced developers nalu . 

usability, or user interface prototypes ra u y work more productively this way. Thus, productivity 

performance prototype for very talented architects may increase when given free- 
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dom to iterate as necessary. On the other hand, anecdotal 
evidence tells us the opposite is likely true for inexperienced 
developers. 

This is not to say that application developers should never 
iterate — it's really a question of degree. One approach is to 
use selected application developers on scout teams that form 
for one-time efforts and then disband. These efforts may, for 
example, address an initial pilot process or other type of 
prototype mentioned above. Even then, these efforts are 
usually best coordinated by an experienced developer, pre- 
sumably from the frameworks team. 
For Difficult Tasks Plan Three Iterations 

For those aspects of the system that require iteration, the 
question still remains, How do I know when I am done? 
Experience has shown that three iterations are usually 
required, for example: 

design and develop initial working model 

refined working model and pilot 

roll-out and support 

The need for three iterations has been observed in so 
many cases that some consider it a magic number. For 
example, the three iterations defined above parallel very 
closely a maxim quoted by Kent Beck, a well-known 
Smalltalk expert, Make it run, make it right, make it fast. 
Difficult Components Should Be Designed and Then Pro- 
totyped 

An initial working model phase designs and prototypes 
the component or framework. Prototyping may be necessary 
to evaluate two or three alternative approaches. In these 
cases the initial design represents a strawman, until receiv- 
ing validation from implementation. Only then can things be 
finalized and reviewed for sign -off. 
Piloting Reusable Components with Developers is Neces- 
sary 

During the refinement and piloting phase, the component 
or framework is completed with any remaining functionality 
and then used in a pilot case. Coordination is often necessary 
with a pilot developer who is a client of the reusable piece, 
to ensure that it works in an appropriate use case. Typically, 
the pilot process generates several refinements or changes. 
Pilot developers need a flexible, positive attitude to handle 
potential instability. 

r Y\\G component must then be documented and rolled out 
for reuse to all developers. In many cases, the roll-out 
requires a formal group meeting to answer questions. 

During the support and refinement phase, the component 
is refined as other use cases generate new requirements, and 
bugs or performance problems are identified. Although the 
implementation details of the component should not be 
widely known, it is critical that developers thoroughly 
understand the purpose and public behaviors of the compo- 
nent. If they do not, then they may not be able to effectively 
reuse and debug interactions with it. 

Summary 

A traditional client/server implementation often incorpo- 
rates some limited iteration with a waterfall approach. This 
iteration is usually confined to technology architecture tasks. 
Component-based systems tend to require somewhat greater 
iteration for three key reasons: 

Reusability often requires actually reusing the component 

to ensure the reused piece meets requirements 
Component technology is new, thus iteration helps 

address greater technical risk 
Component skills and methodologies are emerging, there- 
fore the team often gains valuable experience from 
iteration 
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Managing iteration is difficult but possible. Usually the 
plan must incorporate a hybrid of waterfall, incremental, and 
iterative models as appropriate. The right process depends 
on the organization or teams' skills, the degree of technical 
5 risk, and the specific application and business requirements. 
Testing 

Testing typically consumes anywhere from 50-80% of 
development effort. Despite this relative importance, testing 
receives little emphasis by component-based 
1Q methodologies, which focus primarily on analysis and 
design techniques. This section presents testing lessons 
consistent with the primary themes in The Testing Process 
Practice Aid, produced by the Re-inventing Testing Project. 
These points merit increased emphasis, however, because 
experience has shown component-based systems increase 
15 testing complexity. 

Testing Is More Complex 

While a component-based approach may be simpler to 
test than a strictly object-oriented approach, testing is still 
more complex than a procedural system, because component 
20 architectures: 

decompose into a much greater number of components 
than equivalent procedural modules, introducing more 
complex technical integration 
achieve a greater level of reuse, which is a blessing once 
highly reusable pieces stabilize, but remains a substan- 
tial challenge while they undergo development 
utilize flexible, messaging between components that cre- 
ates a larger number of potential test execution paths 
30 usually develop with some degree of iteration, which 
jeopardizes the benefits of phase containment 
Testing Requires More Phases 

The Testing Process defines a three-step process, very 
similar to traditional Method/I, as follows: 
35 component test — a test of an individual module or pro- 
gram that is specified and coded as a single unit 
assembly test — a test of a set of programs that commu- 
nicate with each other via messages or files, usually 
equivalent to a user interface dialog or a batch string 
40 product test — a test that verifies the technical and func- 
tional implementation supports the business process 
Object Systems Require an Initial Atomic Test Phase 

When building components using objects, testing can 
logically follow these same three primary phases, at a high 
45 level, preceded by an initial atomic test phase. An atomic test 
phase is required because a well-factored object system may 
typically have at least 10 times more objects than procedural 
modules in a traditional system. This finer granularity 
requires testing and integrating more units at multiple levels. 
50 Completing a Window Requires Several Stages of Compo- 
nent Test and Integration 

A traditional approach often defines the initial component 
(unit) test as a working window, front-to-back. In a 
component-based architecture, on the other hand, a window 
55 may often utilize behaviors of several components. This 
results in too much integration for an initial component test. 
In fact, several stages of integration must occur to complete 
a single window. 

Consider a customer that encapsulates other related com- 
60 ponents such as credit profile and address. This customer 
aggregation even represents too much functionality for an 
initial component test. Simpler components such as the 
address must be tested first. Testing individual components 
or tightly coupled aggregations should occur in the initial 
65 component lest phase. 

The assembly phase then tests the integration of these 
components. This test phase differs from a traditional assem- 
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bly test, because more components must typically be converse is also true — mistakes tend to penalize all devel- 

integrated, particularly for the vertical, front-to-back func- opers. Thus, thorough testing and attention to quality in early 

tionality from window to database. This adds to the hori- development steps is important, 

zontal integration of interdependent windows in a dialog. In Iteration Complicates Phase Containment 

contrast, a traditional assembly test concentrates much more 5 Yet, incremental or iterative development complicates 

heavily on the horizontal dialog test, since the front-to-back P hase containment. Phase containment presumes a waterfall 

window functionality is often just a single module. model - For example, a module or component should not be 

The timing of the assembly test may vary depending on P 888 * l ° a la | er phase such as coding until the design has 

the development teams organization. If there are a numberof be * n validated and verified. In contrast, overlapping design 

developers working on a functional slice of the application, 10 !? d cod f e ™* h ? s cod f f ^ mCOm ^ t deSlgD ' 

4 . r . . : ? . , i . • i This puts at risk any efforts to define precise milestones so 

then early integration helps to ensure that developers are tQ cflfcctivc £ track ^ 

working in concert and simplifies integration later. UenUion R ires More DeUiled Exit Criteria 

Conversely, the issues of integration may not be as signifi- iteration rcquires more delailed coition criteria. 

cant if a single developer is working on an entire business For example) different iterations of design must have very 

function, end to end. 15 explicit scope boundaries to ensure that the completion of an 

In summary, the collective atomic, component, and iteration is adequately defined. These must be accompanied 

assembly test phases require much more detail in terms of by strong adherence to proper procedures as components are 

milestone definitions, status tracking, and methodology promoted through various development stages. Even with 

development. such efforts, however, experience has shown that later 

Testing Component Collaborations Must Occur in Several 20 designs tend to impact previously working code. Significant 

Phases regression testing must be expected, as discussed below. 

The process of testing and integrating behavior of col- Automated Regression Testing Is Usually Necessary 

laborating components must occur at multiple levels. In Regression Testing is Necessary because of Iteration, 

particular, distinguishing between the component and Inheritance, and Extensive Reuse 

assembly test phases can seem somewhat arbitrary. A well- 25 Experience has shown that the higher degree of reuse in 

factored architecture may have identifiable boundaries, an component model and application framework makes it 

however, as noted above. Thus, coming up with good very difficult to protect implemented components from 

definitions of aggregation — that is, cohesive groups loosely subsequent development. Developers must then verify pre- 

coupled from other groups, is equally critical to testing as to viously tested components as they incrementally add func- 

design. The component aggregation must then support an 30 tionality to the system. Automated regression testing can 

effective partitioning of the application architecture and save time by ensuring that areas that are impacted by 

team organization. changes are properly tested. 

Testing Requires a Flexible Organization Moreover, regression testing capabilities are absolutely 
On large projects, the set of components involved in a essential if an extensive architecture framework is devel- 
business event are often developed by many different 35 oped. Component-based development allows an application 
people. Thus, the complexity of team integration further framework to abstract both technical and functional behav- 
complicates the testing effort. Well-defined component iors. This greater level of reuse necessitates that the frame- 
boundaries in the software and organization are certainly work evolve with the development of the application, 
key. However, the organization must expect the need to Unfortunately, this implies changing the technical environ- 
support flexible integration testing teams that form to ensure 40 ment of the application even as it approaches delivery. To 
a particular business function works correctly across parti- effectively support these enhancements requires re-testing at 
tions. many different levels. 

Testing Effort Shifts Earlier In Development Using Objects Increases the Need for Regression Testing 

The System Test Phase Should Go Faster When developing components using objects, regression 

The implications of greater modularity and flexibility 45 testing becomes even more important. For example, inher- 

discussed above increases complexity in the atomic, com- itance often results in sub-classes coupled to their parent. A 

ponent and assembly tests. Once the architecture and highly parent class may have side effects with subtle implications 

reusable components in the component model stabilize, to children, which are difficult to identify for test cases, 

however, system test is simplified. Thus, component-based Experience has shown that even seemingly innocuous 

systems require shifting testing effort earlier in the devel- 50 changes to a parent can damage previously tested sub- 

opment lifecycle. classes. 

Phase Containment Requires Greater Attention In general, an inherited feature must be retested in the 

Experience has shown that defects become increasingly context of the subclass. Retesting can only be avoided if 

more expensive to fix later in the development cycle. Phase subclasses are "pure" extensions of their superclasses; that 

containment strives to decrease both the number and cost of 55 is, if they don't override any methods and do not modify 

fixing errors, by testing steps early in the development inherited instance variables. Furthermore, test cases usually 

lifecycle through verification and validation of work. FIG. cannot be inherited when overriding a method. Slight dif- 

49 illustrates a V-model of Verification 4900, Validation ferences in logic and data declarations are indeed enough to 

4902, and Testing 4904. Exit criteria might involve, for invalidate the superclass* test cases, requiring new test 

example, compulsory detailed checklists or code reviews 60 definition and input data. 

before work is promoted to the next phase. All of the above considerations result in substantial 

While phase containment is not unique to component re -testing. Enough so, that a manual approach to regression 

development, its importance is heightened. Since many testing can be extremely cumbersome. In particular, changes 

portions of the component model may be reused by literally to shared components or changes at or near the root class of 

every window developer, quality is critical, That is, a high 65 a deep inheritance hierarchy can have widespread impacts, 

quality design and implementation for core components Thus, automated facilities for testing should be considered a 

increase the productivity of every developer; however, the mandatory element of component development. 
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Combine Automated Testing with an Automated Build Pro- 
cess 

Automated testing can also make the configuration man- 
agement process more efficient. By using an automated test 
process to verify that the latest version of the application is 
working correctly, it is possible to give the development and 
testing teams more stable releases. For example, simple 
defects such as incorrect interfaces can be detected before 
the application is even distributed. 
GUI Scripting Tools Alone Are Usually Not Sufficient 

Capture -playback GUI testing tools have proven effec- 
tive. However, for many applications these are not com- 
pletely sufficient. These tools may only re-validate that the 
application appears to function properly. Experience has 
also shown that applications may sometimes use widgets or 
technical elements of the user interface not supported by a 
particular tool. 

Self-testing Features Should Be Built 

A more comprehensive testing framework should be 
considered that incorporates the notion of self-testing com- 
ponents. That is, the component may have behaviors, or 
indeed contain a tester component, that feeds the class a test 
suite, and validates the resulting behavior. Note, however, 
that test components rarely test behaviors of just a single 
component in isolation, because any meaningful behavior 
usually cuts across multiple components. The test can still 
obey encapsulation, though, by testing the group as a single 
black-box, rather than taking short cuts which may under- 
mine the validity of the test. 
Testing Frameworks Requires More Attention 

The use of frameworks in component-based systems also 
increases the complexity of testing. Frameworks add com- 
plexity for the following reasons: 

Foreseeing all the uses of a framework is hard a priori. 
Thus, verifying correct behavior is difficult because the 
test cases may not be complete. 

The test approach can require extensive scaffolding to 
support emulating the application intended to use the 
framework. 

Framework development is usually undertaken early in 
the project so that it is ready to support application 
developers. This implies incomplete knowledge of 
requirements for the frameworks team. 

The stakes are high, because the framework usually 
provides a reusable structure for many developers. 

There are essentially two methods for testing a frame- 
work: 

Emulation approach — by building a comprehensive test 
environment that emulates the application. 

Pilot approach — by using application developers as pilot 
users in the testing process. 

The emulation approach protects application developers 
from the testing effort, and is generally more consistent with 
a formalized approach. Not doing so opens the door to 
rolling out untested frameworks. On the other hand, creating 
a redundant simulation environment of the application use 
cases can be expensive. 

The pilot approach may be more productive by leveraging 
real application code. In addition, it encourages training and 
knowledge transfer to developers. Finally, it helps ensure 
accurately covering requirements. It is important to use 
application developers for the pilot, not the architects. This 
may provide an objective review of the framework's usabil- 
ity. The primary drawback is that it takes a developer away 
from the application; and, as noted above, may result in 
frameworks developers feeling relieved from thorough test- 
ing. Experience has shown that a hybrid of the two is usually 
necessary. 
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Summary 

Experience has shown that initial component develop- 
ment projects require more effort in testing. On the other 
hand, the later stages of testing can be more productive by 

5 effectively leveraging encapsulation of components and 
large-grained components. There is reason to believe that 
these benefits can be leveraged sooner if the team pays 
increased attention to testing early in development. Testing 
should be a part of the entire development process compris- 

10 ing: 

phase containment principles with explicit objectives and 
exit criteria such as checklists and peer or lead reviews 
automated regression testing capabilities 
self-testing components 
15 more detailed testing phases and milestones 

comprehensive procedures with disciplined enforcement 
Development Architecture Considerations 

This section highlights key messages for development 
architecture teams in regard to supporting teams and tools 
20 within a component based development project. 

Building systems that are dramatically more responsive to 
change require a dramatically improved development archi- 
tecture. 

What does it mean to be more responsive to change? The 
25 solutions one builds must be more: 

Flexible. Making it possible to replace or modify appli- 
cation components with minimal impact to the other 
components in the system. 
3Q Scalable. Giving you freedom to distribute and reconfig- 
ure application components to meet the scalability 
requirements of the client. 
Integratable. Allowing you to reuse the functionality 
within existing systems by wrapping them as compo- 
35 nents within the new application. 

Adaptable. Giving you freedom to deliver an application 
to a variety of user types through a variety of delivery 
channels with minimal impact to the application itself. 
Reusable. Making it easy to quickly assemble unique and 
40 dynamic solutions from reusable components. 

Component-based development pushes us forward on all 
of these dimensions, and although it's relatively immature, 
we're better off than we were before. Metaphorically 
speaking, we've climbed very close to the top of the 
45 mountain that represents traditional development. The view 
is satisfactory, but we know there is something better, so 
now we're climbing the mountain that represents 
component-based development. We have yet to reach the 
top, but we're already higher than we were before. 
50 On every component-based development project, teams 
spend time evaluating and establishing the environment in 
which analysts and developers create the deliverables. A 
workbench must be established that expedites the flow of 
deliverables through the different phases of the project. In 
55 component- and object-based solutions, these phases are 
very connected. This is largely because each subsequent 
phase tends to be an elaboration and refinement of the 
deliverables completed in previous phases. In addition, there 
is a strong desire to link deliverables and requirements from 
6 q the ear her phases to the deliverables from the subsequent 
phases. 

On a typical project one finds the following tools used in 
the software development process: 

General diagramming tools: Visio, ABC Graphics, etc. for 
65 workflow and operation diagrams 

MS Office: Word class and component specification 
templates, Excel scenarios, 
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Object Oriented CASE tool: class and component models, 
component/class specifications, message trace dia- 
grams 

Database design tools: Erwin, Oracle Designer, etc. 

Integrated Development Environment(IDE): Visual 
Studio, Visual Age for Java, JDeveloper, Visual Cafe 

Source code configuration manager: SourceSafe, Clear- 
Case 

An inordinate amount of time is invested in the macro 
process of how to capture and link information in a way that 
it can be used effectively through the course of the project 
(e.g., moving the models from the CASE tool into the source 
code of the targeted IDE environment). Teams should tackle 
early the selection of deliverables in each phase and which 
tool the deliverable may be created and maintained within. 
In addition, they should determine whether the deliverable is 
to continue to be enhanced in subsequent phases of the 
project through the iteration process. 

Today's dilemma ... no easy answers, yet 
To realize an environment that enhances the productivity 
of your analysts and programmers is a challenge for any 
project, but for projects building component-based 
solutions, it's even more difficult because of the technolo- 
gy's relative immaturity. You won't find any easy answers, 
yet. 

Generally speaking, the resulting environment gets the 
job done, but consists of tools that are crudely integrated 
with no central repository. This results in redundant data and 
manual cross-referencing. It can also cause problems during 
the transition from Design to Construction % a gap that's 
always been difficult to traverse. Other typical concerns 
include a tool's ability to meet usability, scalability, and 
multi-user requirements. 

Ideally what would greatly increase the productivity of 
the development architecture is a seamless integration of 
tools in the workbench and the ability to "plug in" whatever 
tool is most appropriate for the capture and communication 
of a particular deliverable. FIG. 50 portrays a development 
architecture with a seamless integration of tools which can 
be plugged in for the capture and communication of par- 
ticular deliverables. Shown in FIG. 50 is the relationship 
between a process phase 5000, deliverables 5002, tools 
5004, repositories 5006, and an information model 5008. 

One solution center working on this architecture found 
that the current state of integration with tools was so 
constraining that the picture in FIG. 50 had to be resolved 
with many compromises for new component work. There 
were many custom scripts created and manual processes 
defined for leveraging the flow of information between 
phases and tools. 

FIG. 51 shows a design architecture with the compro- 
mises made for today's component construction environ- 
ment. Shown in FIG. 51 is the relationship between pro- 
cesses phases 5100, deliverables 5102, tools 5104 and 
storage 5106. 
Key Considerations 

A development architecture should provide an environ- 
ment for component-based solutions that supports a team 
through the Analysis, Design, and Construction phases of 
the development process. It should also serve as a productive 
environment for the on-going maintenance of an application. 
Conceptually it should integrate all of the necessary tools 
through an information model and most ideally through a 
central repository. The following are considerations that all 
component development architecture must consider. 

1. Support Custom Process. The present invention uses a 
robust process for developing component-based solutions. It 
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includes deliverables that are above and beyond the Unified 
Modeling Language (UML). Furthermore, projects often 
customize it. The environment must provide the ability to 
extend the information model (i.e., the meta-model). 

5 2. Versioning & configuration management. The environ- 
ment should provide the ability to version objects within the 
common information model at any level of granularity, 
keeping track of these changes over time. It should provide 
the same ability for composite objects (i.e., configurations of 

ao smaller objects). 

3. Scalability. The repository-enabled environment must 
be able to support hundreds of users simultaneously, and 
hundreds of thousands of repository relationships. It should 
also scale downward, so that small project can use it. This 

15 is a major criterion for usability. 

4. Query and impact analysis. As organizations begin to 
maintain their own component-based assets, they must be 
able to analyze the impact of change requests (e.g., where - 
used searches). The ability to trace requirements is also 

20 critical. 

5. Asset catalog (reuse). As organizations begin to reuse 
existing assets, it may become increasingly important to 
provide a catalog of components, frameworks, patterns, etc. 
The catalog should make it possible to search for relevant 

25 assets in a wide variety of ways. It should also provide a 
means for applying frameworks and patterns. 

6. Code generation. The ability to generate the application 
structure from the model is essential to high productivity. 
Furthermore, this step should be transparent to the user. As 

30 far as the user is concerned, a change to the model is a 
change to the code. 

7. Desktop Tool Integration. The repository -enabled envi- 
ronment must provide integration between all desktop tools 
(e.g., MS Office, Visio, OO CASE tools, designers, etc.) 

35 through component object models such as ActiveX. In 
addition, these tools must have access to the common open 
information models. 

8. Non-redundant storage. The environment should avoid 
redundant storage of information, whenever possible. 

40 Everything from training to documentation to active com- 
ponents should be automatically updated or notified of 
changes. 

9. Multiple users and locations. Many users may need 
access to the environment during the course of a develop- 

45 ment effort. Furthermore, because one supports global com- 
munities of practice, there is a strong need to share this 
information securely and across disparate locations. 
A Development Architecture Needs to Support Customiza- 
tion of the Process 

50 UML & Case Tools in the Development Architecture 

Each project using component-based technology deter- 
mines how to use OO CASE tools to support an object- 
oriented methodology and its deliverables. These deliver- 
ables range from high-level business process documentation 

55 in the business-modeling phase to descriptions of classes in 
the construction phase. UML compliant CASE tools provide 
a number of the deliverables that most object methodologies 
uses, however, there are almost always some deliverables 
that do not fit in the selected tool. There is also a discrepancy 

60 with the CASE tools' ability to comply with UML due to the 
continuing evolution of UML versions. 

UML has become so universal now that deliverables from 
most methodologies form a superset or, in some cases, a 
subset of the deliverables described by UML. In the case 

65 where a deliverable is a close match to a UML deliverable, 
proprietary scripting is required to allow for complete 
semantics. This scripting is also used to migrate from the 
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CASE tool to other drawing or word processing tool. Pro- 
cedures must also defined to effectively use the tool to 
support the process. 

Decide on Supported Deliverables Early in Process 

Case tools in recent years have extended their ability to 
support more of the life cycle and improved their ease of use. 
In addition, some case tools have improved their integration 
with the Integrated Development Environments (IDEs) and 
produce some level of acceptable component code genera- 
tion. It is important for the development architecture team to 
determine early exactly which deliverables may be created 
in each phase of development, which tool they may be 
captured in and whether links between phases require 
upgrading deliverables as a result of the transformations 
and/or enhancements from other phases. 

The team must decide how much they may leverage the 
automated tools to support the build process. An investment 
in the macro infrastructure can lead to tremendous time 
savings as the construction process is supported. The team 
needs to determine early whether they may "build" their 
custom process into the tool or adjust the process to better 
integrate with the tool. 

Development Architectures Are Often More Heterogeneous 
than Traditional Environments 

While traditional client/server systems typically required 
one development tool for programming efforts, component- 
based systems are often built using several tools and pro- 
gramming languages. The increase in tools is directly related 
to the improved capability to integrate software components 
through interfaces that hide the implementation details. 

Typically, the more heterogeneous environments may be 
built upon the open CORBA technology, while applications 
developed with JavaBeans or COM may tend to be more 
homogeneous in nature. Thus, it is important to understand 
the technologies used as the effort to design a cohesive 
development architecture may be impacted. Plan to spend 
more time designing and building the development archi- 
tecture for a heterogeneous environment. 
Configuration Management 

The advent of client/server has focused significant atten- 
tion on the importance of configuration management as key 
to success. Configuration management is more than just 
source code control. It must encompass the management of 
the application software components from conception, 
through implementation, delivery, and enhancements. While 
the problem is not unique to component and object 
development, an object-oriented environment presents spe- 
cial challenges discussed below. 

Configuration Management Is More Complex in a Compo- 
nent Development Architecture 

Currently, artifacts versioned with various tools do not 
know about each other. For example, an object versioned in 
a document management tool has no relationship to the 
source code configuration. In addition, various tools are 
advertising the advantages of their repository strategies. 
However, these products are in their infancy and most do not 
integrate seamlessly with the source code configuration 
managers let alone the various tools in a development 
workbench. Models, source code and documentation are not 
synchronized. The reality is that current versioning in the 
majority of tools only occurs at the file level and not at the 
required level of granularity to support development ele- 
ments. Methods, classes, components, and their respective 
deliverables should be versioned but only a few products on 
the market today support this level of granularity and they 
are not yet integrated with popular case tools. 
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Object Systems Are Decomposed into More Pieces 

Configuration management is more complex with object 
development because the system is more finely decomposed. 
Object development realizes the benefits of flexibility and 

5 reusability through a greater level of decomposition than 
was present in traditional systems. While smaller objects 
have the advantage of making it easier to have pre-defined 
building blocks, a disadvantage is that large-scale systems 
have so many elements that managing their relationships 

io becomes difficult. 

For example, a key principle of object-oriented design is 
separation of concern, which decomposes behavior into 
smaller, more cohesive objects. This strategy strives to 
prevent changes from rippling through many objects. The 

is implication of this design approach, however, is that the 
resulting system may comprise many more modular pieces 
than a traditional architecture. This greater decomposition 
complicates configuration management. 

Not only are there more objects than procedural modules, 

20 the relationships and dependencies intrinsic to object devel- 
opment are usually more complex. For example, the rela- 
tionship between business processes and objects is a 
complex, many-to-many mapping: a business process is 
implemented by more than one object; conversely, an object 

25 contributes to more than one business process. FIG. 52 
illustrates a business process 5200 to object 5202 mapping 
to illustrate such relationships between business processes 
and objects. One manager referred to this phenomenon as 
the web of interdependencies. 

30 To manage this problem determine early what the "unit" 
of configuration may be and have the development organi- 
zation aligned with the approach. For example, in the 
previous maze possible units of configuration could be: 
Process I depends on: 

35 Object 1 
Object 2 
Object n 

This keeps the process component rigorously configured 
with its dependent pieces. 
40 Configuration Management Requires a Comprehensive 
Approach 

Most Object CASE Tools Do Not Support a Complete, 
Integrated Repository 

Integrated tools have, thus far, not been found to support 

45 cross-referencing window elements, object model attributes 
and behaviors, and relational database definitions. Thus, 
large projects must consider crafting a strategy to integrate 
multiple point tools to provide such cross-referencing. 
The tools gap raises the importance of rigorous procedural 

50 and organizational models to address configuration manage- 
ment. For example, proper procedures must ensure that 
rigorous quality and build steps are followed before intro- 
ducing a new component into the environment; the workplan 
requires much more detail to track dependencies; and, the 

55 organization structure must effectively support more exten- 
sive communications to react to changes. 
Adopt a Philosophy for Configuration Management that 
Guides the Development of the Process 
There are two fundamentally different approaches to 

60 configuration management in the component world. Simply 
stated, they represent the difference between an optimistic 
approach versus a pessimistic approach to managing 
sources. In the optimistic approach multiple users can access 
and modify the same sources and the tool is leveraged to 

65 resolve conflicts when code is merged. In the pessimistic 
approach a source is locked when it is checked out. Both 
advantages have pros and cons and some source control 
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managers allow the configuration to choose which approach class can release the methods to the class, version the class 

they may choose. and release to the general development team. In this model 

Define Multiple Levels of Ownership editions are open configuration units, versions are any units 

A traditional, procedural system usually assigns owner- that have been checked back in and releases are units that 

ship by business function. Functional developers take on 5 have been made visible to the next construct of configuration 

responsibility for a business function that corresponds to a management. 

front-to-back window. Technical team developers then take In this model clients of lower level components can be 

on cross-function architecture responsibility. This approach added as developers in the integration phase. Rather than 

has obvious benefits in providing straightforward commu- have to wait for a new version of the component, they can 

nication points and division of responsibility. A drawback, 10 concurrently have an edition opened with which they can 

however, is that business function reuse is much more modify or enhance and then submit their changes back to the 

difficult, component owner. This practice can keep control with 

This approach breaks down due to the higher level of component owners but increase the bandwidth of the devel- 

reuse in an object-oriented system. Note that a procedurally opment cycle. 

designed system may also experience this problem to the is Application Packaging Must Have a Clear Release Manage- 

extent that the team strives for a large degree of business ment Strategy 

logic reuse. To support a flexible ownership model requires a detailed 

Owners Must Exist for Every Versionable Component technical packaging strategy. Multiple levels of granularity 

An object-oriented system must assign component own- for controlling source code are typically needed. The method 

ership at multiple levels. Business process owners are still 20 and class are obvious targets for versionable components, 

necessary; however, clear lines of responsibility must be However, levels of granularity above the class are critical to 

assigned for the domain object model. Often these two may properly control the cross-class development that occurs, 

have a tight relationship. For example, consider a gas utility Typically development may occur on groups of classes 

customer system that provides customer service orders. The which can be versioned together as categories or applica- 

service order business process and service order domain 25 tions. In Java, for example, these categories are packages, 

object owner should probably be the same person. However, For example, the frameworks development team may gen- 

the service order process may also need to collaborate with erally have a work-in -process version of the framework 

other key domain components such as the customer and architecture package to support new development. Applica- 

premise. This requires collaborating and communicating tion developers would instead have an older version, typi- 

with other developers. 30 cally the first version, that had been thoroughly tested and 

Rigid Ownership Boundaries May Not Work rolled out. 

Experience has shown, however, that the level of com- It may also be necessary to version groups of methods 

munications with core business objects such as customer and together in a class. This has proved beneficial for managing 

bill account is so high that the rigid ownership might be object model development. 

ineffective. The resulting communications of requirements 35 Components of the system should also have a well- 
may produce ineflcient hand-offs and bottlenecks. For large, defined [EWF1] relationship between them. This should 
mission -critical applications, multiple levels of ownership occur at each level of granularity and give a definite feel for 
must then be defined. However, this creates a risk of the dependencies between components. Each instance of a 
conflicts. Before components mature, the rules of divisions component also needs to know the specific, tested compo- 
should probably be more rigid. Later, multiple developers 40 nent versions with which they are compatible. It is essential 
can modify common classes, while keeping responsibility to that the relationships between components are non-cyclical 
release, or publish, the code in the hands of a single owner. or layered and that a complete dependency inventory be 

Thus, ownership roles may overlap, requiring the rules of obtainable for every versionable component, 

engagement to be defined. Yet, every scenario cannot be Favor Shorter Shelf Lives to Support Frequent Roll-outs of 

spelled out precisely. The team and leadership must then be 45 Reusable Objects 

very participatory and flexible to adapt to the dynamic One of the most difficult decisions for object development 

requirements. is how frequently to roll-out reusable components to mul- 

One large engagement defined separate, overlapping own- tiple developers. And a related issue is how long component 

ership responsibility for: should sit on the shelf between changes. 

Windows 50 For a traditional, waterfall approach the shelf lives may be 

Domain object model sub-systems, or components; the |° D 8 ™' h few iterations For example, a module is 

model comprised about 350 model objects which were typically coded and then put on the shelf untrl stnng test. The 

partitioned into about 12 major areas ^psed tame ranges from a few weeks to many months. 

1 Likewise, once string tested the module may again sit for a 

Business processes that were particularly complex, highly 55 - dme mm system test long shelf hves typically 

reusable, and cut across many windows; for example, WQrk reasonably wcU unless the underlying data model or 

writing off a bill architecture changes. In this case, unproductive re-work 

Common architecture framework components results. 

Separate concept of ownership from developer for The Object Model Must Be Continuously Rolled Out to the 

increasing productivity 60 Team 

One solution to the above problem is the clear distinction For object development, roll -outs of objects must occur at 

between component ownership and developer rights. This varying intervals depending on the range of impact. Because 

philosophy is supported by tools like Envy/Developer for the object model is continually evolving as completed 

Smalltalk and Visual Age for Java. Assign owners of classes, windows incrementally add behavior, the model must be 

packages, and projects and then assign developers to the 65 continually refined and rolled out to the team. Some of these 

packages. Any developer may write methods on an open changes may have a very narrow impact to just one window, 

edition or checked out copy of a class. The owner of the where others may have more global implications. 
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For example, changes may be rolled out in the following 
intervals: 

Application Interface or Control — nightly 

Narrow Impact Object Model — nightly 

Wide Impact Object Model — coordinated on-demand, no 

more than 1-3 times per week 
Frameworks — weekly or less frequent depending on 

impact, maturity of the component, and the complexity 

of the effort 

Structural Object Model — for Data Waves, Once Per Month 
Object development also requires shrinking the shelf lives 
dramatically. Reusable domain model and framework 
objects generally require a zero tolerance policy for incor- 
rect code. Problems need to be fixed immediately, or at least 
their impact critically assessed and the fix scheduled. As 
mentioned earlier, some of this immediacy can be managed 
with careful process surrounding ownership, editions and 
developers. In one tool there is a concept of a scratch edition 
that allows a non-registered developer to access units of 
control and make changes within his private environment 
and still be able to post the changes back to the component 
developers and owner. This eliminates hours or day turn 
around to correct a critical problem in a versioned compo- 
nent. 

Clean-up or Fix-it Days Must Be Scheduled 

Window or view specific behavior can have a longer shelf 
life, but still not as long as traditional development. Letting 
items sit for more than even just a few weeks can cause them 
to become dangerously out of date. Thus, two different large 
engagements found it necessary to schedule clean-up fix 
days on a regular basis. 

Regression Testing Is Key to Effective Configuration Man- 
agement 

Regression testing is essential to support these more 
frequent clean-up efforts. This approach frustrated 
management, because these days appeared to be a step 
backward or treading water. However, keeping the applica- 
tion clean paid dividends in addressing and fixing problems 
more efficiently. Generally speaking, the longer the problem 
went unfixed, the more expensive they were to correct. 

In summary, a flexible approach is necessary to coordinate 
and control changes. Some considerations include: 

Ability to absorb change — If the developers are over- 
whelmed with change or learning curve, the shelf life 
must be expanded to reduce change. 
Magnitude of the change — Minor changes may be easy to 
incorporate and may facilitate immediate turn around. 
Major changes may be expensive to incorporate except 
at controlled, regular intervals. 
Restart Cost — Each effort to integrate changes into an 
existing component may incur a start up cost for the 
developer. This may again be influenced by the mag- 
nitude of the change, and the duration of the integration 
cycle. A rapid integration cycle may keep the behaviors 
fresher in the developer's memory; a longer shelf life 
may involve a refamiliarization cost. On the other hand, 
this must be balanced against the cost of starting and 
stopping new development to implement fixes. 
Stability — As a component stabilizes and matures, the 
shelf life can be reduced without impacting the rest of 
the project. Unstable object components cannot be 
rolled out as frequently, because the turn-around time is 
longer. 

Delivery Capability — The ability of the migration team to 
provide a "most current" build may also impact the fix 
versus shelf decision. In C++, the build process may be 
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a major undertaking, where the shortest shelf life may 
be measured in days. In Smalltalk, the size of the image 
may likely have a similar affect. In Java the adherence 
to clearly defined packages improves the delivery capa- 
5 bility. 

Configuration Management May Require 5-10% of Devel- 
opment Team 

Configuration management clearly requires more effort 
with object development. These roles are often hard to 
justify to management, because they appear to be pure 
overhead. The tasks may also appear unclear. For example, 
tasks such as "Manage environment" and "Communicate 
changes" do not to have a start and a finish. 

These tasks should be controlled and managed by a 
centralized effort. Several people sharing the effort in their 

15 spare time may not exercise enough caution and due dili- 
gence. Furthermore, a centralized effort may often result in 
automation of tasks producing significant productivity 
improvements. 
At least 5% of the development team should be com- 

20 pletely dedicated to the on-going configuration management 
effort. When setting up and defining the environment even 
more resources may be necessary. Of course, there are 
limits. Stacking the team with too many resources may result 
in wasteful development of an overly elaborate tools archi- 

25 tecture. 

Another approach is to make the configuration process 
implicit in the entire development process. In other words, 
by ensuring that an owner of a class must version and release 
his work before it can be seen by a containing package the 

30 owner is required by the process to be thinking about the 
configuration process in all of his work. Subsequently, the 
package owner, generally a more experienced developer, 
must ensure that all classes are versioned within his package, 
version his package and then release it for general consump- 

35 tion. This would work the same for a project which tends to 
be centered around increasing units of capabilities (i.e. 
business activities and finally whole applications). 
Scaling to Large Teams 

Despite the advice to use small teams, enterprise appli- 

40 cations are large and often require in the aggregate a large 
number of developers. Development architectures must be 
constructed in such a way as to support sometimes hundreds 
of users with many, sometimes hundreds of thousands of 
development artifacts and their relationships with each 

45 other. 

All of the major software development tool providers (i.e. 
IBM, Microsoft, Oracle, Unisys, etc) have announced 
repository strategies. These repository strategies are much 
more comprehensive then the proprietary repositories that 

50 are represented by a source tool repository such as in Clear 
Case for source code or the proprietary repositories shipped 
with Case Tools or development environments like Envy 
Developer and Forte. These repositories allow for informa- 
tion to span tools and strive for integration between not only 

55 tools provided by a single vendor or from a host of third 
parties as well. Many case tool and IDE providers have 
announced support for this new generation of component 
repositories. 

The new strategies all espouse either de facto standards 
60 (Microsoft's Open Information Model) or eventual con- 
formance to a repository strategy (OMG's Meta Object 
Facility — MOF). These repositories, although encouraging, 
are very immature and may require a few years to deliver on 
their promises. In the mean time development architectures 
65 must decide on their own how they may provide the nec- 
essary facilities to promote large team development 
progress. 
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Query & Impact Analysis 

Tools are necessary to identify categories of similar 
behavior such as the class hierarchy, where used, senders of, 
implementors of, etc. Today, many environments for C++, 
Smalltalk, Visual Basic & Java provide robust browsers with 5 
this comprehensive functionality. Additionally case tools 
also provide search capabilities. Unfortunately every tool 
uses a different method for finding artifacts, such as text 
searches for documents, menu provided searches in case 
tools, and where used and senders of within browsers. 10 

As mentioned in an earlier section many of the language 
based IDEs provide sophisticated browsers and explorers 
that allow for searches for "where used" and "senders of for 
messages and objects. These facilities are extremely impor- 
tant in component leveraged architectures. They allow is 
developers to more effectively look for things to reuse rather 
than always re-inventing what they need. One important 
practice to help the searching process is naming standards. 
They should be put in place early in the process to enable a 
principle ParcPlace was fond of calling, "the principle of 20 
least astonishment". Because of polymorphism developers 
become very agile in locating classes and methods because 
their interfaces are so common like all objects responding to 
the "toString( )" method. 

One of the problems in current development architectures 25 
is the redundancy of the facilities. For example, rather than 
be able to rely on the repository where the information 
should be stored in a common location developers may 
search in Rational Rose and in the source code manager for 
references of a given type. 30 

One way to mitigate this issue is to publish information to 
a common location to make it accessible to everyone 
through a common interface, preferably a web browser. 
Tools like JavaDoc and Microsoft Word (which can trans- 
form documents into HTML) make it possible to leverage 35 
the web server's index server to locate artifacts from various 
locations. This practice is being more widely adopted, as 
shown by the release of IBM's JCentral tool. 
Asset Catalog (Reuse) 

One key improvement in component-based development 40 
from traditional development is the use of components to 
assemble solutions. This is very different from libraries. 
Because of the reflective nature of components, runtime 
binaries can be dropped into the development environment, 
their interfaces exposed and then integrated into the current 45 
solution space. This is done through the Java Reflection 
mechanisms within class files and type libraries in the 
Active/X world. 

Currently reuse tends to be at entire source code branches 
rather than component-oriented. This has been provoked by 50 
poor version support in most development environments and 
tools inadequate for managing the assembly and configura- 
tion of components into solutions. Some component man- 
ager tools that are being released onto the market today 
support either the ActiveX or JavaBean component models 55 
but its not clear how they may be received, used and 
integrated into development and design environments. 

To maximize reuse requires the assembly and configura- 
tion of run-time components in addition to being able to 
construct new components as part of the software construe- 60 
tion process. A new breed of tools supporting black box 
reuse referred to as "Component managers" should be 
considered one of the primary tools provided with the 
environment to 1) support transformations between tools 
where this may continued to be a requirement, 2) enable 65 
component views of reuse allowing configuration from both 
run-time and development components and 3) give compo- 
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nent developers security features preventing users from 
modifying and/or reusing certain components if they desire. 
It requires the ability to categorize components and search 
components according to property descriptions in a way that 
can be ascertained without the viewing of source code. 
Code Generation 

In the past code generation was crude, had to be 
customized, and was hard to keep synchronized once source 
code was emitted. This awkwardness was caused by other 
related factors like the lack of a common information model, 
little coupling with the IDE and no common repository 
sources. In addition, the ability of the CASE tool environ- 
ment to comprehend the run time environment was poorly 
supported in most tool environments. The most damaging 
problem is the failure of CASE tool providers to "own" the 
code integration and generation produced from the model. 
Some of the efforts to integrate with IDE's via Add-Ins are 
a step in the right direction but, some key issues, such as 
identity integrity across multiple environments, have not yet 
been addressed to ensure its success. 

That being said, code generation via case tools at the 
structural level can greatly increase the productivity of a 
team when a rigorous model is adhered to in mapping the 
domain model constructs to code or schema in the target 
environment. Two areas have been used to some degree of 
success from component engagements 1) generation of DDL 
from object schema — the domain model and 2) generation 
of the object structure or domain model to the target lan- 
guage. 

One analogy has been made with Layout Managers or 
Screen Builders. A decade ago people were comfortable 
with coding windows by hand. Some even felt that form 
designers were too constraining and got in the way of 
developing a really usable interface. However, no one today 
would think of generating forms by coding them by hand. So 
with the standardization of UML and the maturing of object 
model semantics developers should be reticent to code class 
structures by hand. Oracle refers to this as "one source of 
truth". A change to the class structure in the source code is 
a change to the model and vice versa. 
Desktop Tool Integration 

Desktop tools today generally include an office suite, 
drawing tools, case tools and more recently, a web browser. 
For example, one might find a tool selection like Microsoft 
Office for documentation, Visio for custom deliverables, 
Rational Rose for models, and Internet Explorer for viewing 
HTML versions of the documentation. VBAhas become the 
glue for extending and connecting the information between 
these tools. Other strategies have included using Notes as a 
repository for all of the deliverables that users could access 
information. 

ODM has many predefined deliverable templates that are 
targeted towards this suite of tools including Word, Excel 
and Visio templates. Often times management under- 
estimates the start up cost of integrating the tools in such a 
way as to improve the flow of information between phases 
and for ensuring that information is published to the team in 
a way that is accessible and plentiful. However project 
experience teaches that this investment can yield many 
returns down the road if the development architecture 
includes processes and infrastructure to support this flow of 
information. 

This desktop tool integration strategy needs to take into 
account the comprehensive approach used by the configu- 
ration management strategies. In other words, relevant docu- 
ments need to be associated with the components and 
business processes they update so that key stakeholders can 
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subscribe to alarms that may make them aware of when 
sections of documentation need updating. This process may 
help ensure that the publishing model is dynamic and 
current. 

Many Users and Multiple Locations 5 

Solution Centers and engagements often have many users 
and multiple locations involved in solution delivery. It is 
very important for development architecture teams to solve 
the problems of concurrency within tools and ownership 
across locations. Strategies need to be developed for how ^ 
components may be exported and imported, and supported 
across locations. In addition, an approach for receiving 
feedback for improvements needs to be established. Most 
projects have found that ownership is even more important 
in a distributed development environment. This allows for 
the using of master/slave assignments on components and 15 
dictating either who is allowed to make changes to the 
component or who is responsible for merging changes. As 
one technologist from Sun stated, if distributed development 
is not managed carefully it can be like herding cats. 

20 

SUMMARY 

Although there are new challenges with development 
architecture in a component environment there are also 
additional opportunities for increased productivity. A team 
that understands the additional considerations may weigh 25 
the opportunities that tool integration can bring to the project 
against the practical gap in the market place and customize 
their development architecture accordingly. Wise planning 
and a clear understanding of the strengths and limitations of 
the tools available to a team may contribute greatly to the 30 
success or failure of a project. 
Managing Performance 

Component-based technology is often sold on benefits 
such as reduced maintenance, increased reuse, or flexibility 
to absorb change. Performance, on the other hand, is usually 35 
viewed as a significant drawback. However, resilience to 
change and performance do not have to be mutually exclu- 
sive. 

Component Technology Can Enable Better Performance 

Component-based systems have advantages that can actu- 40 
ally enable better performance — but only if proper design 
techniques are used. This chapter discusses the correlation 
between performance-tunability and a well-designed 
component-based system, and the implications this has for 
project management. 45 

The timing of when to address performance may initially 
appear trivial. "Design performance in from the start" is one 
often-repeated rule. The opposing viewpoint is expressed by 
computer scientist David Knuth who said, "Premature per- 
formance tuning is the root of all evil". Timing when to 50 
address performance is actually a complicated management 
issue. The competing forces and their possible resolution are 
discussed further below. 

Define Performance Goals in Terms of the Business 

An old saying goes, "Cheap, fast and good — I'll give you 55 
two out of three". Many of clients may react negatively to 
this philosophy, because they would certainly like excel- 
lence in all three areas. Yet, the fact remains that difficult 
tradeoffs exist between performance, quality, and the cost of 
the system. For example, no one intentionally designs a slow 60 
system. Thus, it is critical to define performance goals in 
business terms based on cost/benefit analysis. 

Consider service level agreements for online 
performance, which are often based on the average wait time 
between screens. This makes sense in a technical environ- 65 
ment using 3270 display devices. However, this may lead to 
poor business decisions for a non-modal, windowing GUI. 
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A GUI may support a more rich set of processing than a 
3270-based design. This can result in response times much 
slower per window; however, the time for completing the 
business transaction such as a customer order may be 
equivalent or even less. Yet, to tune the performance for an 
equivalent level of window-to-window response time may 
simply not make economic sense. Thus, the requirements 
should be based on how efficiently the system completes the 
pure business event, encompassing potentially multiple 
windows, rather than a more technical measure of window- 
to-window navigation. 
Measure Performance 

Any effort to effectively address performance requires 
thorough measurement capabilities. There are two reasons 
for this. First, the team must understand where the specific 
risks reside, before they can effectively attack them. Is the 
application I/O or compute bound? Is database or network 
I/O a bigger issue? Are there obvious bottlenecks? These are 
all key questions. 

Performance Metrics Focuses Attention and Provides Con- 
fidence 

Second, just the simple act of measuring and tracking 
performance focuses attention in a positive way. Tools such 
as language profilers and memory-leak checkers are critical. 
A rich set of tools can give the team more confidence in the 
quality of their development and technology. 

Confidence is particularly important to object-oriented 
and component-based systems development, because a deli- 
cate balance is necessary between addressing performance 
risks without detracting from good object-oriented design. 
For example, fear of messaging overhead may lead devel- 
opers to avoid altogether factoring behavior into smaller 
methods and objects. Yet, such factoring is critical to appli- 
cation reusability and quality. 

Fear of Object Messaging Overhead Can Be Overstated 

A potential source of misunderstanding is equating object 
messages with network or operating system messages. 
Actually, object message sends are often more comparable 
to function calls, albeit slower. And the overhead of message 
sends compared to function calls can be unimportant com- 
pared to the application I/O. That is, most applications are 
I/O bound, not compute bound. On the other hand, it is 
important to understand the frequency of component mes- 
saging since it may cross network or process boundaries. 
Thus, when looking at messaging characteristics it is impor- 
tant to distinguish between component messaging and 
object-messaging. 

Address Architecture Performance Risks Early 

As with a traditional client/server system, performance 
risks should be addressed early. Performance requirements 
often have a severe impact on the technology architecture 
including the infrastructure design and the platform systems 
software and hardware. For example, the architecture team 
may need to decide whether to use messaging, remote 
procedure calls, or shipped SQL statements for distribution 
services between client and server. Performance may also 
impact fundamental platform decisions such as the choice of 
language, DBMS vendor, operating system, network, or 
hardware configuration. 

Usually these parameters cannot truly be understood 
without constructing a benchmark prototype. In cases where 
the underlying platform is affected, the benchmark should be 
planned and conducted at the outset of the project. These 
measures are important, because intuition may often be 
wrong as to where the problems lie. 

In addition, the technologies thai make up the foundation 
of a component architecture may be new and unproven. To 
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minimize risks, look for a reference application that is the system is being built so that there is time to make 
similar in complexity and size. If a similar application can't changes. Furthermore, it becomes even more important to 
be found, then it may be necessary to develop a proof-of- establish design guidelines early in the project so that 
concept prototype for the architecture. Such a prototype may detailed designs can be reviewed against them. This can help 
address areas such as the middleware, application 5 ensure that performance problems are avoided before corn- 
architecture, or hardware platforms. ponents are implemented. 
Performance Is Balanced Against Encapsulation and Soft- Leverage Points 

ware Distribution ^ e va * ue °* reuse 1S " ec l uea "y perceived as less to 

Performance is Frequently Balanced Against Encapsulation co ? e ' , While ofte ° true > a sometimes overlooked more 

jo*-* r*- * -L „ valuable aspect is less to maintain . This is notably sig- 

and Software Distribution 10 4 , r ~ . . - . ,7 

. , 4 t , ■ • * j cc it— l nificant when performance-tuning a system. It is generally 

As with any system, there are design trade offs that can be worthwhile t0 £ d more time u * determining how to 

made to achieve better performance. With component-based reuse existing components lnan it is to spend less lime 

systems, some of the most significant performance trade offs developing a new solution. Similarly, it is usually more 

are made against encapsulation and software distribution. wort hwbile spending more time generalizing a component 

The encapsulation of data forces applications to access is ^ j t may be reused than it is spending time to develop a 

data through a component's interface. Unfortunately, encap- specialized solution. 

sulation may many times result in excessive messaging, a leverage Point Is Factored Out Behavior that Enables 
sometimes across a network, between components. Thus, Leveraging Global Performance Gains 
performance can often be improved by breaking encapsu- A leverage point is processing common to multiple co ro- 
tation to directly access data. 20 ponents which may be factored out and reused when needed. 

Software distribution is often simplified by utilizing cen- In performance tuning, these points are identified, profiled 
tralized application servers. However, a centralized and tuned, thereby leveraging any performance gains against 
approach may result in diminished performance due to the all components which use them. In general, the less actual 
network messaging. Performance can often be improved by processing an application-specific component (i.e. non- 
distributing software closer to the point of usage. 25 architecture) performs indicates the more performance 

Selecting the right balance between performance, soft- leverage may be gained from it by tuning architecture 

ware distribution, and encapsulation is not easy. Achieving processing. 

the right balance may be driven by system's requirements. For example, a business event controller class in a system 
Performance Tuning Can Be Deferred with Object-Oriented must somehow specify the relationships between its relevant 
Frameworks 30 business components and the widgets which may interact 
Object-Oriented Frameworks Enable Performance Tuning to with them on the application window. There are two fun- 
Be Deferred damental approaches in specifying these relationships. The 
Smalltalk columnist and consultant Kent Beck espouses first is for an initialization method to be invoked in the 
the philosophy "Make it run. Make it right. Make it fast." At controller which may perform the processing required to 
a glance, this advice may seem counter to the previous 35 define these relationships. The other is for that business class 
recommendation to address performance risks early. to specify the bare minimum information required to infer 
However, they do not have to be mutually exclusive. An these relationships such that a common architectural com- 
application should be prototyped — i.e., made to run, early to ponent can perform the actual processing required to define 
address broad architecture performance risks. Later, proper the relationships during runtime. 

design should be the focus before performance, because a 40 The latter approach provides a leverage point for perfor- 
well-designed application enables more productive perfor- mance tuning the initialization of the window. The process- 
mance tuning. Optimized code is simply very difficult to ing may be tuned to use a more efficient algorithm; the 
maintain. And prematurely optimizing code may incorrectly results of the initialization may be cached during application 
assume what problems are most important, thus wasting packaging and read during initialization; or, efficient initial- 
effort. 45 ization methods may be generated and maintained automati- 

Object-oriented system development, in particular, allows cally from the information by a code generator once it 

for a deferred attention to performance. The component becomes clear what the most efficient implementation is. In 

design goal of encapsulating implementation details tends to any case, the flexibility provided by this leverage point 

lessen the impact of major change to the application. This allows many more possibilities to be considered during 

allows sweeping changes to be made late in application 50 performance tuning. Note that all three optimizations could 

development. FIG. 53 is a diagram which illustrates a graph be achieved without manually visiting a single of perhaps 

5300 of resilience to change. hundreds of windows which share the initialization process- 

This graph illustrates the belief that through a good ing. 

object-oriented design, changes related to performance tun- The pursuit of leverage points must be considered in 

ing may be made much later in the development lifecycle 55 every architectural design decision, and followed with dis- 

than would generally be possible with traditional structured cipline in application design. 

design. With an emphasis on good object-oriented design, Communication via Interface Definitions — Specify What 

the degree of radical change possible late in development is Not How 

surprisingly high. On a component-based project where the development 
Non -Object-Oriented Systems Should Be Performance 60 should reuse extensively, the name of a component and its 
Tuned Throughout Development methods are perhaps the strongest medium of communica- 
When components are not built using object-oriented tion between the original developer and a developer inter- 
frameworks, it may not be as feasible to defer performance facing with, or maintaining that component. A fundamental 
tuning. Without frameworks that provide a well-layered and grammatical naming standard is the means to ensure clear 
factored architecture, it may not be possible to make small, 65 communication between developers. This standard must be 
localized changes that result in dramatic performance well-defined, strongly enforced, and supported by leader- 
improvements. Instead, it is better to performance tune as ship. 
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A weak standard of interface definition often results in strong pursuit of encapsulation allows bottlenecks to be 

code requiring extra processing which could be avoided by identified more easily (i.e. in one place), and tuned with 

making assumptions based on a strict interface definition. minimal impact. 

Performance tuning is easily complicated by generic inter- Leverage Functional and Technical Tuning 

faces supported by vague assumptions. Redefining such 5 Though tuning of a component-based application can be 

interfaces late in development is often prohibitively expen- deferred until late in development, eventually it must be 

sive relative to the low cost of clear initial interface defini- done At this point it ^ important t0 realize the difference 

tlo °* , , , „ , . , , between functional tuning and technical tuning. 

An example of a poorly-defined interface is a method Functi onal tuning involves a combination of cognitive 

definition which may accept several unrelated types as Us 1Q and measured ^ 1qq 

parameters. The result leads to type-checking or. parameters , . c tJJi r 

and decreased flexibility in tuning the implementation of the desi S Q of a component and determming which portions of 

method. The strong definition of interface parameters allows Pressing can be deferred cached etc. It demands a 

fundamental assumptions to be made in tuning the imple- developer who is functionally knowledgeable about the 

mentation of the interface. desired behavior, whether it be architecture or application. It 

A grammatically-based naming standard differentiates 15 often results in reorganizing or redesigning portions of code, 

between methods that do versus methods that get. In a The performance gains realized during functional tuning are 

traditional approach, procedures or functions do routines generally the most significant gains, 

and algorithms. The unique blend of data and behavior in Technical tuning is a lower-level approach to tuning, 

component-based development, on the other hand, allows developing more efficient techniques to achieve the same 

components to collaborate, asking each other for data, as 20 functionality. Technical tuning demands a developer who, 

well as directing each other to perform processing. This though not necessarily intimate with the functional 

requires the addition of nouns and the inclusion of verbs to requirements, has a strong familiarity with tricks and tech- 

the vocabulary of interface definition. That is, the interface niques of the development platform. It can involve better use 

should specify what, not how. of memory, language idioms, base class modifications, etc. 

For example, if a customer component provides a public 25 Technical tuning should require little or no changes to 
interface that allows another component to ask it to query the application code, and narrow changes to architecture, 
database for its credit profile, a common mistake is to define Opportunities for performance tuning are found both in 
a method getCreditProfile or retrieveCreditProfile in cus- bottlenecks and in distributed inefficiencies. There are gen- 
tome r. If, however, performance tuning required caching the erally many tools available in detecting bottlenecks. Dis- 
customer may already have the credit profile. This would 30 tributed inefficiencies are usually more difficult to identify 
leave development with the choice of either changing the with tools. Whether performance optimizations are realized 
method name in all referencing components, or create docu- through cognitive analysis, or tool-assisted profiling, it is 
mentation to explain why the method getCreditProfile didn't important to measure the gains against a baseline perfor- 
really get anything, but just provided access to another mance level. 

component. 35 Few performance improvements are gained by eliminat- 

This example illustrates the importance of naming to ing completely useless code. Gains are usually achieved by 

ensure encapsulation. The implementation changes required trading speed for size, or chronologically reorganizing pro- 

to achieve radical performance improvements are feasible cessing. Improvements in one area may weigh in a different 

only through diligence in the pursuit of encapsulating imple- area. For example, runtime processing is often sped up by 

mentation. 40 increasing initialization time. When making such changes, 

Along with good design organization, clear interface measuring the affected runtime processing is insufficient. It 

definition is key in achieving valuable tunability. is necessary to measure also the areas impacted to determine 

Limit Knowledge of Data and Object Relationships that the optimization does not push another area into unac- 

Developers with structured programming experience ceptable response, 

often tend to perceive objects as data, manipulating them 45 

within the context of objects, effectively distributing behav- Summary 

ior associated within components amongst all the objects n - , i j j • i ■ j i ■ 

4 & ,.„. . J Performance is an acknowledged risk in developing com- 

which interact with it. This becomes very difficult to per- , 4 4 , , . ■ , \ *? , 

c _ , . 4 . . r , • c ptex systems with today s maturing component tecbnolo- 

formance tune due to the combination of duplication of • ^ , . , / . • . •* u 

, j . ... , L ■ i j * fiies. To reduce risk and uncertainty, it may be necessary to 

code, and the wide impact any such toning could have on 50 * protot y pes that vaU date the architecture approach, 

application classes. A much greater degree of performance wheD ™ »• afe ^ ugi fich object ™ iemed 

toning can be achieved when object respons.bU.Ues are franleworks ^ j, ible t0 tune , ^ponem-based system 

respected and objects or collaborations of objects can be mofe effectivel £ later in d^op^ lhan its structufed 

tuned in isolation with minimal impact to their embedded . t , \ ft . „ . 

s stem v s5 counterpart. Other more traditional approaches to 

A ■" i i c «j * c - « t_ . . components, may require tuning throughout the develop- 

A simple example of data -lfying objects is when object meo t c cle 

A manages a group of other objects, yet other objects ask 

object A for its managed objects and manipulate them freely. s erv j ces (1020) 
Generally loop iterations are prime candidates for significant 

performance improvements. If the iterations are distributed 60 Batch processing is used to perform large scale repetitive 

over every object that interacts with object A, little perfor- processing where no user involvement is required. Batch 

mance improvement of component A may be gained without support is an often overlooked area in architecture and 

high impact. By restricting interfaces such that only object component design. When first client/server and then com- 

A may iterate over its own managed objects, the iteration ponent technology hit the scene, the emphasis on GUI and 

code can be tuned with little impact outside object A. 65 communications was so strong that many thought of batch as 

Performance improvements can always be identified. The dead. Today, one is wiser about including batch in the scope 

difficulty is in the cost of actually implementing them. The of both architecture and application efforts. One also finds 
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that many of the principles and concepts that applied to 
batch twenty years ago also apply today. 

In general, batch still has the following fundamental 
characteristics: 

Scheduling — Services are required to manage the flow of 
processing within and between batch jobs, the interde- 
pendencies of applications and resources as well as to 
provide integration with checkpointing facilities. 
Restart/Recovery — Batch jobs must be designed with 
restartabilily in mind. This implies the need for a batch 
restart/recovery architecture used to automatically 
recover and re-start batch programs if they should fail 
during execution. 
Controls — Run-to-run and integrity controls are still 
required to ensure that all data is processed completely. 
Reporting — Services are required to handle configurable 

report creation, distribution, printing and archiving. 
These services are typically not provided through com- 
ponent technologies. They can be provided by third-party 
products or custom implementations. 
How is batch different in a component-based system? 

A system's batch architecture can be easily overlooked 
since it is not a part of the system that is visible to end-users. 
Regardless, it is critical to design components with both 
on-line and batch requirements in mind. Combining both 
sets of requirements is necessary to ensure that your com- 
ponents can be used in both environments. This will allow 
the batch programs to act as just another client to your 
components. 

In addition, since many on-line systems are expected to be 
available on a 24x7 basis, there may be a limited window 
available for exclusive batch processing. This requirement 
can have a tremendous impact on your batch architecture. In 
these environments, it is necessary to design batch programs 
that make efficient use of resources and have a low impact 
on on-line users. 

A component -based batch architecture must support batch 
programs that read transactions that are really messages. 
These message transactions are read either from a flat file or 
from a database. The program must then locate the compo- 
nent for which the message is intended and pass the message 
to that component for processing. In many cases, these will 
be the same components that process messages from on-line 
(GUI) applications. The function of the batch "program" in 
this environment is fairly limited. It reads the input 
messages, controls the packaging of database units of work, 
and sends requests to the business component that performs 
the actual business logic associated with the messages. 
Batch architectures usually "commit" on intervals that are 
designed to optimize database resources. Thus, it is impor- 
tant to design components that can participate in a logical 
unit of work that is controlled outside of the components. 
How do the patterns in this section help? 

The patterns described in this section represent some 
initial attempts to capture basic concepts that are useful in 
the design of a component-based batch architecture. They 
are by no means exhaustive but represent building blocks in 
a complete solution. 

The Batch Job pattern describes a method of structuring 
batch components so that common architectural services are 
implemented uniformly across all of these components. In a 
way, this is the component-based analog to the concept of 
shell designs and skeleton programs which have been a 
recurring feature of robust batch architectures for many 
years. 

The Batch Unit of Work (BUW) pattern, on the other 
hand, represents a method of structuring the work to be 
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processed by the batch components so that it too can be 
treated uniformly by all components. An abstraction such as 
this forms the basis for distributing batch workloads in a 
number of useful ways. It also enhances the capability of the 
5 architecture to support evolutionary change. 

The Processing Pipeline pattern describes a way of struc- 
turing batch activities so that they can be easily reconfigured 
as processing requirements change. This pattern directly 
addresses the issues of scalability and reuse in a component - 
]0 based batch system. 

The Abstraction Factory pattern has a much broader 
applicability than just batch systems. It represents a way to 
encapsulate diversity such that only those parts of the system 
that need to understand the difference between two objects 
15 have to deal with those differences. To use a typical batch 
example, a file is a file is a file. Only those components that 
require knowledge of the contents of a file should need to 
deal with those contents in other than a very generic way. 
What are some other considerations in developing a 
20 component-based batch architecture? 

Because batch processing executes on a server and 
requires limited user interaction, many of the services used 
for on-line architectures are not needed. For example, the 
services used for distributing components — naming, distrib- 
25 uted events, bridging, trader, etc — are not needed for a batch 
architecture. In fact, the interfaces that encapsulate compo- 
nents and provide location transparency can add significant 
overhead to a batch architecture. To avoid the expense of 
unneeded services, the component stubs can be wrapped 
30 with a layer of indirection that short-circuits the normal 
distribution mechanisms. This will provide performance that 
will approximate local function calls. 

Typically, business objects have to be instantiated from a 
relational database (RDBMS) before the batch application 
35 can make use of them. This extra overhead is a very real 
concern. It is an unfortunate fact that in many ways the more 
"object-oriented" your design is, the worse it fits into the 
relational paradigm of rows and tables. For one thing, these 
designs tend to have lots of objects with embedded instances 
40 or references to other objects. And the primary reason that 
such designs have RDBMS performance problems is that in 
the database, resolving such an object relationship requires 
joins or recursive queries. When mapping from your object 
model to the RDBMS, there is a tendency to "normalize" 
45 your object over many tables, and the performance can 
easily plummet. 

Is efficient component -based batch hopeless? No. But if 
you have stringent batch performance requirements, you 
may need some specialized design. There are several tech- 
50 niques you can use to improve your batch speed. 

Reduce (eliminate, if you can) batch. This may sound 
simple and stupid, but is often overlooked and is by far 
the cheapest way to improve your batch yield. Lots of 
reports can be obtained on-line, lots of them are not 
55 useful or used, "trigger transactions" can simply 
become spawned sub-processes that run in the 
background, same for printing bills, the only thing that 
must be done in batch is a database reconciliation, 
which requires a time window with no other activity. If 
60 you can engage in discussions for eliminating batch, by 
all means do. 

Pool (recycle) objects. Each time you dispose of an 
object, instead of destroying it put it in a pool of 
recyclable objects; and every time you create a new 
65 object, look in the pool to see if there is one that can be 
recycled. Keep separate pools for each class of objects. 
Allocating objects is a lot more expensive than one 
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tends to think, and recycling can improve your batch 
performance dramatically without affecting your 
design. 

Cache and sort. This technique is well known to "tradi- 
tional" batch designers, but it is so obvious that they 5 
don't even think of it. However, it has a correspondent 
object implementation. Keep a small cache of objects 
you have just read from the database. Most of the times, 
one instance of each is plenty. Whenever you need to 
access an object on the database, look to see if it is 10 
already in the cache. If not, read it and put it in the 
cache too. Encapsulate all this logic in a technical 
"Table" object — not in the business objects. At the 
same time, organize the processing of your data in a 
sequence that maximizes cache hits. Again, this tech- 35 
nique does not affect your "business objects" design. 
The processing cost of this technique is so low that you 
can keep it enabled also for on-line, thus simplifying 
your technology architecture. 
For some applications, an LRU caching policy might not 20 
be the right choice; a more complicated scheme with mul- 
tiple cache levels might be necessary. For this reason it 
would be best to make the caching policy itself be an object 
(consider the Strategy pattern for making an object from an 
algorithm) so you can change the policy on demand. 25 
Cache operations and accesses. One of the reasons 
component-based batch performs so poorly is due to 
the fact that, in order to maximize modularity and 
preserve encapsulation, a lot of operations are per- 
formed redundantly. For instance if a balance is imple- 30 
mented as a calculation, and if it is needed by six 
different objects it is recomputed six times. These 
situations are very easy to identify with a performance 
monitor that tells you where the program spends most 
of its time; it is not uncommon to find that most of the 35 
time is actually spent in very few methods. For these 
methods (and only for them!) cache the result in an 
instance variable. Every time the method is invoked, 
check if the instance variable contains an answer: if not, 
compute it and store it there; if yes, just return it. Of 40 
course, each operation on the object that invalidates the 
result of the computation must invalidate the cache too! 
This technique has a very small impact on your object 
design and typically leaves the interface unchanged. 
Cache objects. Typically, this would involve leaving 45 
recently referenced objects instantiated in memory for 
some length of time after their last use. Then, if the 
object is accessed again, you check the memory- 
resident cache before re-loading the object from the 
DBMS. Usually you would construct this cache as a 50 
hash table keyed by object ID, and use a LRU policy to 
keep the cache size manageable. Expect degraded per- 
formance if you do anything to destroy the utility of the 
cache. For some applications, LRU might not be the 
right choice; a more complicated scheme with multiple 55 
cache levels might be necessary. For this reason it 
would be best to make the caching policy itself be an 
object (consider the Strategy pattern for making an 
object from an algorithm) so you can change the policy 
on demand. 60 
Make use of "lazy" or "deferred" loading. That is, don't 
do a "deep" instantiation until you know you're going 
to use the associated parts of the object. Instead, load 
selected sub-objects only when first referenced This 
can save on memory overhead as well as DBMS access. 65 
In some cases you can use a hybrid strategy: do a 
"shallow" instantiation by default, but provide the 
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client program with a way to build the complete object 
on demand to provide more deterministic performance. 
One thing to be careful of with this approach is that if 
you really do tend to use most parts of the object during 
high-volume processing, loading it in piecemeal can 
actually worsen the performance, because of the over- 
head of maintaining the load state and because of the 
smaller DBMS transactions sizes. These techniques 
have a very small impact on your object model. 
De-normalize your database where possible. Typically 
when one does object- to-relational mappings, one tends 
to make every unique object type a separate table. This 
is best from a design perspective. But in cases where 
you know you have a fixed set of "private" associations 
(meaning physical aggregation with no possibility of 
shared references), then fold that sub-object data into 
the enclosing object's RDBMS table. It's not pretty, but 
it can save lots of extra loading time. Also, look at ways 
to do aggregate loads based on some unique object ID. 
For example, if you have collection-valued sub- 
components, insert the object ID of the enclosing object 
in the sub-object tables and do aggregate loads in code, 
rather than doing a "point-of-use" instantiation for each 
one separately. Of course, these optimizations can have 
a more substantial impact on your object model. 
Consider making "light" versions of some of your objects. 
That is, for performance critical situations, create alter- 
nate implementations of your business objects that 
don't have all the baggage of the first-class objects. Yes, 
this can be ugly and more difficult to maintain. But for 
many batch processing applications you might find that 
you can drop a lot of the (persistence-related) com- 
plexity of an object without affecting the batch pro- 
cessing at all. Then create fast hand-tuned routines to 
instantiate the "fight" objects from the database. 
As can be seen, there are a lot of opportunities for 
improvement in component-based batch performance. 
However, in order to manage risk early, remember that the 
areas in which you will have trouble are those in which batch 
excels (predictability, repetitiveness) and component-based 
design trades off performance for flexibility and encapsula- 
tion. Message overhead and similar language related issues 
are unlikely to be critical. Obviously, before doing any of 
these things you should do some serious benchmarking to 
see where you're coming up short on performance. Often the 
overhead comes from surprising places. Don't twist your 
object model all out of shape without first having some solid 
performance measurements. 
Abstraction Factory 

FIG. 54 illustrates a flowchart for a method 5400 for 
providing an abstraction factory pattern. Data is received 
and transformed into a plurality of concrete objects in 
operations 5402 and 5404. Each of the concrete objects is 
associated with an abstract interface in operation 5406. A 
map of the association between the concrete objects and the 
abstract interface is created in operation 5408. In operation 
5410, when request is received which includes an identifier 
for one of the concrete objects and an identifier for the 
abstract interface. The map is consulted to locate the con- 
crete object that has been identified in operation 5412. An 
abstract object is then created that corresponds to the located 
concrete object in operation 5414. 

The identifiers may be included with a single request. In 
another aspect of the present invention, the abstraction 
factory pattern may be written in a C++ programming 
language. As an option, the located concrete object may also 
be inserted into the abstract object. With this option, the 
abstract object may operate as a handle. 
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It is desirable to separate concerns between architecture/ extended to perform "Java Loader-like" dynamic link- 
framework and implementation details. One way to do this ing if the proper code cannot be found already within 
is to exploit the power of polymorphism, using an abstract the factory. 

interface to a concrete object which implements that inter- Fa the well )am/ Uem from Gamm3j et al 

face. How, then, is one to create these concrete instances and s , c 

manipulate them within a framework while preserving the BUW > m whlch lhe ob J ects created b V * e factor y can be 

framework's independence? dealt Wlth genencally in terms of independence, 

In any complex information processing system, there will scalability, parallel processing, etc. Component Solu- 

be a variety of different types of information, with a corre- ^ ons Handbook, 

sponding variety of actions which must be taken to process 1Q Batch Job 

that information. One of the difficulties in this task involves FIG. 55 illustrates a flowchart for a method 5500 for 

taking an information source and creating an appropriate representing a plurality of batch jobs of a system each with 

internal representation for it. a unique class. In operations 5502 and 5504, an abstract 

The typical approach to this problem takes the form of a class 0 f abstract data required by a plurality of batch jobs is 

large switch/case statement, where each case deals with one provided and a plurality of batch job sub-classes are defined, 

of the information types. The switch/case approach leads to 15 Each batch job sub _ class inc i u des batch specific data, and 

components that are very difficult to maintain, extend, b - c for rocessing the abstract data arjd me batch specific 

debug, etc. and also leads to a procedural Programming data ^ execution thereof> Each of the batch job 

style. This approach also makes it extremely difficult to , . ■ , , . u , . . . t . es J n£ 

J , j i - t t . t t j * i j j sub-classes is represented with an object in operation 5506. 

properly manage dependencies so that the details depend on T 4 . _*. no , e J . ,. \ . .„ , 

ihe framework and not vice-versa. 20 In operataions 5508 and 5510, one of the objects is identified 

With this in mind, some alternative approach must be used and th ? ^ of the batch job sub-classes associated with the 

which will allow a framework to handle multiple informa- identified object is thereby executed, 

tion types in a way which encourages good style, In one aspect, the data may include a name, a current 

modularity, extensibility, and framework independence. status, messages encountered during a run, various times, 

Therefore, one transforms the various types of raw data 25 and a priority. In another aspect, the abstract class may 

into a corresponding variety of concrete object types, all of include default logic for running a batch job. 

which share a common abstract interface. This transforma- i n an additional aspect, the abstract data and the batch 

tion will be encapsulated within an Abstraction Factory. specific data may be stored separately. In a fourth aspect, the 

The primary interface to the Abstraction Factory is: log j C 0 f the batch j ob sub-classes may be executed by a 

"abstractType produceForKey(key)" 30 scheduler, 

where "abstractType" is the type of the common abstract A ^ of , - , operations may need to be initiated 

interface, and key is a piece of information which identifies m fa SQme , schedulin means , ^ ^ a ^ 

the appropriate concrete type. (This could be the same piece Qf common such as activatioDj lo m and error 

of information used in the switch/case statement; there could h ^ d]in ^ wm faave tQ be Hed ^ • h& Hqw 

beavanetyofw^stogetiO.Whenthismethodismvoked 35 can ^ cQmmQn seryices be distributed l0 all t of 

the Abstraction Factory consults its internal mapping and ba t c h jobs? 

creates an "empty" object of the proper concrete class. The , . j-.j <• . . 

factory then casts the concrete object into the abstraction and Most business systems today include some sort of batch 

returns it to the method's client. This client (a framework Pressing. Batch processing is the execution of a senes of 

most likely) will then instruct the abstraction to initialize M mstmct.onsthatdo notreqmre anymteract.onwitha userto 

itself from the incoming data stream. 40 C0 »P lete - B ** h J obs are usuaU y stot ^ u f dunD S * e ^ 

At the end of this process we have an abstract handle to and e * cuted dunng evenmg hoUK when the SyStem load 15 

a concrete object which a framework may then manipulate ypica y ower. 

generically. ^ nce a * )atc * 1 J 0 * 5 begins, it continues until it is complete 

Benefits or ^ encounters an error. 

Software Quality. Exploiting this pattern can allow us to 45 An architecture that supports batch jobs usually has 

avoid one of the major pitfalls of procedural certain characteristics. It must be able to support checkpoints 

programming, the switch/case statement. Done prop- and rollback, restart and recovery, error handling, logging, 

erly you get better modularity, testability, maintenance scheduling, and resource locking 

and extensibility. 50 Most systems, including those that are component-based, 

Frameworks. The layer of abstraction introduced allows require this sort of architecture. A difficulty arises when 

us to build frameworks which follow the open/closed considering component-based systems though. In a 

principle, that is to say, they are open to extension by component-based system, the application architecture is 

the addition of new concrete types, but are closed to the usually very separated from the business application classes, 

necessity of risky and costly modification 55 In many cases, the business classes and components are built 

Implementations of this pattern will vary widely depend- without regard to the surrounding architecture, 

ing on the selection of language. For example, in C++ a It is expected that the business components will execute 

generic factory, based on templates can be constructed, and in some environmental container that will provide many of 

key — concrete type pairs can be registered to the appropriate the architectural services (like batch services), 

instantiation of the class. This might require manual coding 60 Some natural representation of the batch architecture must 

in other languages. The key interfaces, however are: be developed and transparently integrate with the existing 

Abstraction Factory business components and still support all of the architectural 

AbstractType produceForKey(key) requirements. 

Abstract Type ' Therefore, represent each type of batch job in the system 

init(some data stream) 65 as its own class. An abstract class (BatcbJob) will exist from 

The Abstraction Factory can be fully coded in C++. It is which all specific types of batch jobs will derive from. The 

very re-usable as it stands. In addition, it has been abstract BatchJob contains data that all batch jobs require: 
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name, current status (pending, started, finished, deleted), Therefore, one creates an abstraction which represents a 

messages encountered during its run, various times batch unit of work. Now the design tension comes in. 

(submission, start, completion), and a priority, for example. Clearly one common abstraction is easy to parallelize, but 

It also should provide some default behaviors including no t very interesting to manipulate due to its very generic 

running the job and logic to execute before and after the run. 5 nature (at least if you're interested in type safety). This 

FIG. 56 illustrates a class diagram of the batch job quickly leads us to design a shallow tree of more interesting 

hierarchy. abstractions, and again one's clean scaling model seems 

Various system batch job classes can subclass from the threatened 

abstract BatchJob 5600 and add their own required attributes The k is tQ ^ ^ WQrk units ^ kvel abstraclions 

and behavior. A Bdl Customer* batch job may need the ^ are ^ rQuted processing nodes and to 

identifier of the customer to bill and the time period for , * ■ ♦ a • j u * u 

which to bill. These should be attributes added to the treat th , em as more interesting derived abstractions when 

concrete subclass: BillCustomerBatchJob 5602. In addition, mternal t0 a Dode - gating them as topmost abstractions 

the concrete class needs to supply the actual logic that the between t nodes P™ 1 ^ f g * P r0Cessin S' 

batch job performs (along with any pre- and post-run logic). as lv P lcal actl0ns llke IO/persistence, recovery, auditing, etc. 

Finally, the concrete batch job class should provide some 15 can often be treated uniformly for all types, 

way to start-up all of the pending jobs in its class. A class Treating work units as derived abstractions while internal 

method is implemented on the abstract class to start all to a node is achieved by actually creating the abstractions 

pending jobs. This method can be overridden by any con- within the node. See the Abstraction Factory pattern for 

crete extension of the BatchJob superclass. details on one way to achieve this. 

By implementing batch job instance as any other type of 20 So are we safely scaleable now? Not necessarily. There is 

object, the batch architecture may then take advantage of the still the danger that a given processing node will be pre- 

same system services available to all other business objects sented with a unit of work it cannot deal with, 

in the system (persistence, transaction management, error Kind of like asking a parking meter for a hot pastrami, 

handling, logging, security, etc.). This situation can be avoided with proper workflow, or with 

Benefits 25 sufficient structure, a dynamic library loading version of the 

Natural Representation. Each type of batch job is repre- Abstraction Factory could, in effect, tell the parking meter 

sented by an object. This allows it to interact with the how t0 fix sandwiches. This of course, has the effect of a one 

rest of the system in a natural way. t { me performance hit as the processing node is instrumented 

Extensibility. By providing an abstract superclass, adding new capabilities, 

new types of batch jobs only require adding a new 30 implementations of this pattern will vary widely depend - 

concrete class to the system. mg 0D the selection of languages and technical architectures. 

Architectural Separation. Batch Jobs that are not imple- key ^ that the all work units in the system are derived 

mented "inside" the object-oriented environment can from a si le abstraction> ^ abstraction contains key 

still be tracked by the batch job objecte. The rest of the ^rixxs ^ are iate at the workflow leveL Derive d 

system is unaware of the batch job objects^ 35 abstractions add mlerfaces „ needed fictionally. 

FIG. 57 illustrates an object interaction graph of a pos- 4 t . r 4 . ... tL i 

sible implementation of the example of FIG. 56. FIG 57 Abstraction Factory, in which concrete objects are created 

illustrates a batch scheduler 5700 which interfaces a b £ the fact0 <> ' and returned t0 me Factor ? s chent as an 

BillCustomer Class component 5702 which in turn inter- abstraction. CSH. 

faces a BillCustomer BatchJob component 5704 Processing Pipeline 

ISO New England energy eXchange. A net-centric inter- 40 FIG ' 59 ^™tes a flowchart for a method 5900 for 

net system build for managing functions associated structuring batch activities for simplified reconfiguration. In 

with a competitive energy market. The energy operation 5902, a series of processing steps are prepared for 

eXchange is implemented in Java across client and performing on input objects being streamed into a batch 

server components and using CORBA as a communi- processing system. Each of the processing steps is encap- 

cations architecture. 45 sulated within a filter in operation 5904. The input objects 

Batch processes are often highly resource intensive. In are received and processed in the filters in operation 5906. 
many cases the required throughput demands the use of In operation 5908, results are delivered from the filters 
multiple processors, possibly distributed, to provide seal- incrementally during the processing of the input objects for 
ability. How, then, should one structure one's batch work- reducing latency and enabling parallel processing. In opera- 
load to facilitate a robust and scaleable system? so tion 5910, connectors are utilized for connecting at least two 
BITW filters each having a processing step for creating a process. 

One of the primary- techniques used to achieve scaleable One of the filters is an input filter of the process and another 

batch applications is parallel processing. There are many of the filters is an output filter of the process. Connectors are 

different types of parallel processing, but the simplest and also used in operation 5912 for connecting input and output 

easiest to exploit occurs when the problem domain contains 55 filters of different processes for forming a scalable system, 

many independent work items. In this case, the work can There may be several instances of a particular type of 

simply be divided among the available processors, providing filter running in parallel. A portion of the filters may be 

nearly linear scaling. active and a portion of the filters may be passive. In such a 

Happily, this is exactly the situation encountered in many situation, the active filters may pull input data and data may 

batch systems. However, also given the nature of batch 60 be pushed into the passive filters. Additionally, the input 

processing, the variety among the various work items will filter of the process may be an active filter and the remaining 

likely be large. This of course leads to the need to treat some filters of the process may be passive filters, 

items differently than others, and there goes the nice clean The connectors may perform the steps of acting as a choke 

scaling model. point for data to be pulled from a filter, connecting serial 

With this in mind, some alternative approach must be used 65 filters defined as independent processes, and/or multiplexing 

which will allow a cleanly scaleable framework to handle to demultiplexing from several filters of the same type 

multiple heterogeneous work types. running in parallel. As another option, one of the filters may 
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be positioned between the input and output filters of the 
process for translating an output of the input filter into an 
input type of the output filter. 

How do I define a disciplined strategy to structure the 
components performing processing steps within a batch 
system so that the system is cleanly partitioned while 
maintaining performance and scalability goals? 

Often batch processing systems perform a series of pro- 
cessing or transformation steps on input objects that are 
streamed into the system. Implementing such a system as a 
single component is not feasible for several reasons: por- 
tions of the component must be developed by several 
developers, requirements are likely to change and it is 
difficult to cleanly partition the modules resulting in a highly 
coupled system. 

Compounding the difficulty in implementing the system is 
the fact that most batch systems must satisfy the following 
challenging requirements: 

Must be able to satisfy extremely stringent performance 
criteria. 

The system must scale to meet client's volume. 
The system must be flexible enough to be adapted to various 
contexts. 

These requirements are difficult to meet for any system, 
and batch systems' stringent demands often lead developers 
to think they cannot use component technology. Building a 
procedural batch system to satisfy the requirements listed 
above may result in a complicated set of modules that are 
difficult to maintain as the system is scaled. By utilizing 
component technology's ability to manage complexity 
through encapsulation, a component-based batch system can 
more easily be defined with clean partitioning than when 
using a procedural paradigm. Defined with foresight, this 
partitioning enables the system to scale to meet difficult 
performance requirements. 

Therefore, encapsulate each processing step within a filter 
component. A filter consumes and delivers its results 
incrementally, rather than consuming all of its input before 
producing output. The incremental nature of filters allows 
them to significantly reduce latency and enables true parallel 
processing. 

A supplier provides the input to each filter, and the filter's 
output flows to a consumer. Suppliers and consumers may be 
objects that read files, databases or queues, other filters or 
any type of object supplying or accepting data. In order to 
produce a flexibly arranged system, connect the initial 
supplier, the filters and the final consumer with pipe com- 
ponents that are responsible for implementing the data flow 
between adjacent filters. 

As a result of filter processing's incremental nature, one 
or more filters, tied together with pipes, define a process's 
Logical Unit of Work (LUW); i.e., the filters defining the 
steps of the process are sandwiched by the beginning and 
ending of the transaction. Expanding this model, each sub- 
system representing the LUW can be modeled as a filter with 
input and output that encompasses the internal filters. These 
filters are then tied together through the use of pipes to 
represent the system. In this manner, the Processing Pipeline 
pattern offers a consistent way to view the system that scales 
to whatever size and degree of complexity the system grows. 
Benefits 

Scalability. Each filter performs its data processing and 
transformation independently of other filters. By lever- 
aging off some pipe forms' multiplexing/ 
demultiplexing techniques, there may be several 
instances of a particular type of filter running in par- 
allel. 
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Partitioning. As a result of encapsulating each processing 
step within a filter component it becomes easier to 
manage the balance between coupling and cohesion 
since there are disciplined and well-defined interfaces 
5 surrounding the components. 

Flexibility. Since filters make little assumptions about the 
world around them, they can be arranged in any man- 
ner; several filters can be combined together and 
wrapped by a larger-grained filter; filters can be 
10 dynamically assembled at run-time depending on some 
context, etc. 
Filters 

At a high level, there are two types of filter components: 
active filters and passive filters. An active filter pulls input 

15 data from its suppliers, processes the data and outputs the 
result to its associated consumer. In contrast, input data is 
pushed into a passive filter, which then performs its pro- 
cessing step and outputs to its consumer. 

Typically a system is defined by an active filter at the 

20 beginning of the Processing Pipeline, that pulls input data 
from the data source and initiates further processing by 
pushing the data to a chain of passive filters situated down 
the pipeline. Often the active filters are only responsible for 
pulling data into the system, while the core business func- 

25 tionality is performed by passive filters. 

Because active and passive filters demonstrate different 
levels of pro -activity, it is useful to further break down the 
type of consumers and suppliers into four general types: 
push suppliers, pull suppliers, push consumers and pull 

30 suppliers. These four simple abstract interfaces help segre- 
gate the fundamental, yet disparate, behaviors. Active filters 
inherit both from PullConsumer and PushSupplier. Active 
filters' sources inherit from PullSupplier, and their destina- 
tions inherit from PushConsumer. Passive filters inherit from 

35 PushConsumer and PushSupplier. Passive filters' sources 
inherit from PushSupplier, and their destinations inherit 
from PushConsumer. 
Pipes 

While filters define the basic processing steps, pipes 
^o define how to flexibly configure the system. Pipes can be 
used to connect filters in a wide range of configurations: 
Acting as a choke point for data to be pulled from an 
active filter 

4s Connecting serial filters defined as independent processes 
Multiplexing to/demultiplexing from several filters of the 

same type running in parallel 
Pipes may use buffering, multiplexing and 
de-multiplexing techniques in order to transfer data between 
5Q filters. Some examples of useful pipe implementations 
include: 

Channeled Pipes. Perhaps the most generally useful form 
of a pipe is based on the CO RBA Event Channel object, 
which can connect any number of Push/Pull Suppliers 

5S to any number of Push/Pull Consumers. 

Multithreaded Pipes. These pipes route data to one of 
several filter threads. The data can then be joined back 
to the primary thread on the other end of the filter with 
a demultiplexing pipe. 

60 Database Queue Pipes. These pipes wrap around a data- 
base queue to enable seamless data transfer between 
processes. 

The various command shells enable filter programs to be 
tied together into a Processing Pipeline. 
65 Collaborations 

Abstraction Factory. Often filters will need to produce 
new data objects from input but are only aware of the data's 
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abstract interfaces. As a result of this generality, the filters 
will need to utilize an abstraction factory to produce con- 
crete objects without knowing their concrete class types. 

Business Logic Service Patterns (1024) 

As is stated in the Component Technology Architecture 
Framework, "Business components are the core of any 
application, they represent concepts within the business 
domain. They encapsulate the information and behavior 
associated with those concepts. Examples of business com- 
ponents include: Customer, Product, Order, Inventory, 
Pricing, Credit Check, Billing, and Fraud Analysis These 
are the components that in many cases have been the most 
elusive for reuse but hold the highest promise for attacking 
the cost of development. In this area there are at least three 
targeted categories of business components, Common Busi- 
ness Components, Common Business Services and Com- 
mon Business Facilities. 

Common Business Components are those components 
from the preceding list that encapsulate key business con- 
cepts. At one level these components represent cross appli- 
cation components that are common to a plethora of appli- 
cations. These include concepts like Customer, Company, 
Account, Shipment, etc. These common components nor- 
malize how basic behavior surrounding common business 
concepts can be normalized. Common Business Compo- 
nents are very concerned about the validity of the relation- 
ships they have with other components and ensuring that the 
information relationships are maintained correctly. 

Common Business Services deal with the higher level 
services that abstract out the "Business Unit of Work" or 
more transactional aspects of business processing. Having 
components that capture key processing concepts normal- 
izes the processes for handling business events. These are 
services like credit checks, ordering, servicing problems, 
shipping, product selection, etc. They tend to capture busi- 
ness practices and when reused enable a company to increas- 
ingly leverage the value of those practices. 

Common Business Facilities are those services that deal 
with areas of more engineering component type reuse. These 
include base common facilities like reason codes, currency 
management, telephone and address manipulation and vali- 
dation of these common business types. 
How do the patterns in this section help? 

The patterns described in this section represent some 
initial attempts to capture basic concepts that are useful in 
the area of Common Business Facilities. They are by no 
means exhaustive but represent building blocks in a com- 
plete solution. Both provide tremendous value in solving 
two key challenges which appear on every engagement. 

The Constant Class pattern describes a facility for ensur- 
ing correct data at the attribute level. 

The Attribute Dictionary describes a facility for encapsu- 
lating architectural mechanisms within business objects. 
Attribute Dictionary 

FIG. 58 illustrates a flowchart for a method 5800 for 
controlling access to data of a business object via an attribute 
dictionary. A plurality of attribute values for a business 
object are stored in an attribute dictionary in operation 5802. 
A plurality of attribute names are provided in the attribute 
dictionary for the stored attribute values in operation 5804. 
Next, in operation 5806, it is verified that a current user is 
authorized to either set or get one of the attribute values 
upon a request which includes the attribute name that 
corresponds to the attribute value. The attribute value in the 
attribute dictionary is obtained or updated if the verification 
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is successful and an indicator is broadcast upon the attribute 
value being updated in operations 5808 and 5810. 

In one embodiment, a list of the attribute names may be 
outputted in response to a request. Additionally, the list may 
5 also include only the attribute names of a portion of the 
attribute values of the business object that are present. 

In one aspect, the attribute values may be obtained for 
auditing or rollback purposes. In another aspect of the 
10 present invention, a dirty flag may be set upon the attribute 
value being updated. 

Typically, business objects include "getter** and "setter" 
methods to access their data. How can I support value-added 
processing, such as logging events for changes, without 
15 impacting application code? 

Typically, business objects store attributes in instance 
variables. The application code for a typical setter for an 
attribute is depicted as: 



public void setBalance (Float newBalance) { 
myBalance - newBalance; 
return; 



Initially, this is straightforward. However, after all of the 
attribute setters and getters have been coded, the need may 
arise for an event to be broadcast each time an attribute is 
updated. The code for a simple setter would need to change 
to become: 



35 public void setBalance (Flo at newBalance) { 

myBalance - newBalance; 
this. notify Changed( M Bala nee"); 
return; 

} 

40 

Now each attribute setter must contain the call to the 
'notify Changed* architecture method. This implementation 
forces architecture mechanisms to be intrusive to application 
code. Moreover, addition or extension of architecture pro- 
45 cessing should not impact business logic. One new line of 
code alone may not seem like a large burden on application 
developers. However, many other architecture requirements 
might later affect each setter or getter. 

As another example, before updating an attribute, a check 
may be required to determine if the current user has security 
rights to update attributes. Also, after successful update, a 
dirty flag may be set, or an audit log may be performed. The 
code for each setter now looks as follows: 

55 



public void setBalance( Float newBalance ) { 
// keep track of my original balance, 
// for post-change processing, then do 
// some pre-processing to check 
// that the user has access rights 
Float oldBalance - myBalance; 
this.assertCanSetAttribute( "Balance" ); 
// finally update the balance, then 
// broadcast, set the Dirty Flag, 
// and log 

65 myBalance - newBalance; 

this.notifyChanged( "Balance" ); 
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-continued 

this, make Dirty 0; 

this.logChanged( "Balance", oldBalance ); 

} 



Thus, each added architecture framework for gets and sets 
must be manually added to all getters and setters. Such 
changes impact application developers during coding and 
maintenance. Moreover, they also complicate business logic 
with technical details. 

Therefore, the application architecture should control 
access to a business object's data. This will separate out 
reusable, technical, architecture details. Business objects 
should use an Attribute Dictionary to provide an architec- 
tural hook for attribute getters and setters. Moreover, this 
framework should handle all architectural processing related 
to the update and access of data, transparently to application 
logic. 

Rather than using instance variables, the Attribute Dic- 
tionary holds all attribute values for the object. This dictio- 
nary is a collection, keyed by attribute names. Then the 
architecture can provide generic architecture methods to get 
and set attributes in the dictionary. 

Business objects could each delegate directly to the 
Attribute Dictionary within the attribute getter and setter. 
However, rather than having each business object talk 
directly to the Attribute Dictionary, simple helper methods 
can be created in a superclass for business objects. This 
simplifies the interface for application developers, who do 
not need to know about the Attribute Dictionary. This also 
allows for business object specific logic to also be added 
prior to and after the dispatch to the Attribute Dictionary. 

The code for a simple setter now would look like: 



class Account extends BusinessObject { 
public void setBalance( Float newBa lance ) { 
// set my balance with the new value 
// passed in. The architecture will handle 
// any technical details related to 
// setting the data. 

this.setAttribute( "Balance", newBalance); 

} 
} 



The architecture superclass will then perform the follow- 
ing: 

get the original value, perhaps for auditing or rollback 
purposes 

check if the user has security access to set the attribute 

update the attribute on the Attribute Dictionary 

if successful, broadcast and log the change 

The Attribute Dictionary would then contain the code to: 

update the value for the given attribute name 

set the dirty flag 

This illustrates that both the superclass facade and the 
Attribute Dictionary can have different processing. In 
general, one generic location for getting and setting 
attributes supports (but is not limited to): 

logging 

broadcasting 

dirty flag 

security checking 

NULL field value handling 
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This logic will be either in the facade methods (for any 
code that is business object specific), or the generic methods 
on the dictionary, thereby shielding developers from this 
added complexity. 
5 Benefits 

Maintainability. Architecture code can be added and 
changed in one place for all objects, without change to 
the application code. 
10 Flexibility. The implementation of the storage mechanism 
can be changed as needed to improve performance. 
Readability. The methods used in application code to 
retrieve and update fields on the object are generic. 
35 These methods do not have excess architecture code to 
detract from the purpose of the method. 
Object Model 

FIG. 60 illustrates the manner in which the AttributeDic- 
tionaryClient 6000 is the facade which delegates to the 

20 AttributeDictionary 6002. For example, business objects 
would inherit this behavior. AttributeDictionaryClient 6000 
probably wouldn't be the immediate superclass, but it would 
be somewhere in the hierarchy. In this manner, stateful 
business objects, like Account or Customer, can easily take 
advantage of the Attribute Dictionary. 

The attribute Values attribute on the Attribute Dictionary is 
shown as an instance of the HashMap class 6004, which 
stores key value pairs. The HashMap Collection is used to 

30 provide access to attribute values based on the attribute 
name. This is required for a direct lookup of values associ- 
ated with attribute names. Such lookup can use string 
representation of the attribute names. 
Object Interaction Diagrams 

There are four interactions for this framework: Simple 
Attribute Getter, Simple Attribute Setter, Failed Attribute 
Getter, and Retrieval of Attribute Names. FIG. 61 illustrates 
the internal implementation of the dictionary. 

40 FIG. 61 depicts the use of the containsKey( ) method 6100 
on the HashMap to ensure that the value will exist before the 
get( ) method is used. This proactive search for the value 
ensures that the nullPointerException is not thrown from the 
AttributeDictionary. The performance of such methods will 

45 be checked during testing. If such processing is not 
performant, the code can be altered and the call to 
containsKey( ) removed. In that case, the HashMap will 
need to wrap a try-catch block around the get( ) method. 
FIG. 62 illustrates a method 6200 that dictates that any 

50 nullPointerException that is thrown would be caught and 
rethrown as the more user- friendly exception in the attribute 
dictionary pattern envronment. FIG. 63 illustrates the Get 
the Attribute Names method 6300 in the attribute dictionary 

55 pattern envronment. 
Public Interface 

The following are methods on the AttributeDictionary. 
The AttributeDictionaryClient exposes similar public meth- 
ods. 

60 

public Object getAttribute(String attributeName) raises 

AttributeNotFoundException; 
The return value of getAttribute( ) is typically a wrapped 
primitive, or Java type, for most attributes. This includes, for 
65 example, an account balance (Float) or account number 
(String). The return value of these wrapped primitives must 
be cast, as illustrated in the following example: 
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class Account extends BusinessObject { 
public Float getfialanceO { 
// get my balance using the superclass facade 
// cast the return value before returning it 
return (Float)( this.getAttribute( "Balance" )); 
} 

} 



Other methods on the Attribute Dictionary include: 

public void setAttribute(String attributeName, Float 
attribute Value); 

public void setAttribute(String attributeName, String 
attribute Value); 

public void setAttribute(String attributeName, Busines- 
sObject attribute Value); 

These overloaded methods create a generic interface to 
the AttributeDictionary for attribute setters. They ensure 
type checking, such that no attributes will be set to a value 
other than those for which an overloaded method exists. 

public String[ ] attributeNames( ); 

The method attributeNames( ) returns a collection of the 
names of only those attributes that have been populated (or 
set) on the dictionary. This might be useful for other 
frameworks, which may want to iterate over all attributes. At 
any particular time, a business object may not contain all of 
its attributes (e.g., because of partial retrieval from the 
database). So this may be a subset of the full attribute list for 
the object. 
Constant Class 

FIG. 64 illustrates a flowchart for a method 6400 for 
managing constants in a computer program. In operation 
6402, a plurality of constant names are provided with each 
constant name having a corresponding constant value. The 
constant names are grouped into constant classes based on 
an entity which the constant values represent in operation 
6404. Access is allowed to the constant values in operation 
6406 by receiving a call including the corresponding con- 
stant name and corresponding constant class. 

In one aspect, the constant values may be changed upon 
being accessed. In another aspect, the constant value may 
also include an enumeration. Also, in one embodiment, 
accessor logic modules may be assigned to a plurality of the 
named constants with the accessor logic modules being 
executed upon the accessing of the corresponding constant 
value via the accessor logic module. Also, the accessor logic 
modules may be edited per the desires of a user. 
Additionally, the constant values may be accessed without 
the accessor logic modules. 

Literals are hard-coded constants referenced in multiple 
places. How can source code refer to literals in a maintain- 
able fashion? 

The concept and value of named constants have been 
realized for quite some time. The idea can date back to 
Assembler language naming memory locations where data 
was stored. The purpose is to give the ability to refer to fixed 
values by the name of what they represent rather than by the 
quantity they are set to. 

Named constants allow a programmer to "parameterize" 
a system. This allows a programmer to change a constant's 
value in a single place rather than every place the constant 
is used. In addition to the maintenance gain, readability is 
also increased. 

Many languages offer mechanisms to implement named 
constants. These include PoolDicttonaries (Smalltalk), 
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enums (C and C++) and public static final declarations 
(Java). Difficulties arise during implementation of these 
mechanisms with respect to type constraints, visibility, and 
type checking. 

5 Using these traditional approaches, results in global 
namespace for these literals. This can result in name colli- 
sions. For example, the name HIGH to define a large 
magnitude could translate into different values for different 
uses. A HIGH temperature could be 95 while a HIGH 

10 altitude could be 39000. 

In addition, constants often belong to logical groupings. 
For instance, STOCK, BOND, and OPTION are all types of 
financial instruments. These belong in a some sort of col- 
lection. 

25 A consistent, quality method to represent constants in an 
object-based system is required. 

Therefore, represent named constants in a separate class, 
grouping categories of constant values together within one 
name space. Constants tend to naturally fall into logical 

20 groupings. Each grouping should be represented by its own 
class. For instance, all of the constants used by a Phone - 
Number object to capture the various types of PhoneNumber 
(i.e. home, business, fax, cell, pager, etc) can be accessed 
through a PhoneTypeConstants class. 

25 If constants are obtained by other means than explicit 
language constructs like "public final int HOME_ 
ADDRESS" than public accessors are used to insulate a 
client from changes in how the constant is obtained. In this 
case the values of each of the constants should be defined 

30 privately inside the Constant Class. Public accessors are 
then provided for clients to obtain the constant values. This 
allows for "changing constants". Business- related values 
that may seem constant at design and construction time very 
often are not. Some of these "constants" may eventually 

35 require some logic to determine their value. If clients obtain 
constants through accessor methods, no changes.(except 
within the accessor) will have to be made if the logic is 
added. This is a particularly safe practice when program- 
ming rules dictate all constants to be stored and retrieved 

40 from database tables. 

In the case where constants are defined within the class 
itself most OO languages, excepting Smalltalk, allow for 
some type of const definition. In this case by using a const 
construct (i.e. static final int PhoneNumberType FAX=new 

45 PhoneNumberType( )) it is not necessary to have public 
accessors and private definitions. Declare the class type, 
create static final instances of the type and do not provide a 
public constructor. This ensures the type safety and provides 
easy to access members in the Eiffel style. 

50 Moreover, public accessors in either strategy provide for 
type-safe enumerationsf Enumeration is a special type of 
constant that deserves attention. A TypeConstant class can 
provide enumeration by implementing some key methods 
that provide for supporting iteration over the elements of the 

55 enums. In Java, for example, this entails implementing the 
Enumeration interface. 
Benefits 

Maintainability. Groups all valid values together and 
ensures they can not be created or passed as parameters 
60 by any other method. 

Type Safety. Enumeration values can be type-checked by 

a compiler in method parameters and return values. 
A common application pattern where this use of constants 
was applied was in the modeling of instances vs instance 
65 types where the types added no additional behavior. In two 
different customer care applications this came through as the 
objects like PhoneNumber, PhoneNumberType, RatePlan & 
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RatePlaniype, etc. This example has not yet been updated to 
JavaBeans. 



package Party; 

import java.u til.*; 

public class PhoneNumberType { 

static final Vector types - new Vector( ); 

static final PhoneNumberType FAX - new PhoneNumberTypefO, 
"Fax"); 

static final PhoneNumberType CELL - new Phone NumberType(l, 
"Cell Phone"); 

static final PhoneNumberType HOME = new PhoneNumberType(2, 
"Home"); 

static final PhoneNumberType WORK « new PhoneNumberType(3, 
"Work"); 

static final PhoneNumberType PAGER = new PhoneNumberType^, 
"Pager"); 

private final int phone NumberTypeOrd; 

private final String typeld; 

private PhoneNumberType(int i, String id) { 

phone NumberTypeOrd = i; 

typeld - id; 

types.addElement(this); 

} 

public final static Enumeration elements( ) 
{ // allows for enumeration 
return types.elements( ); 

} 

public static void main(String args[ ]) { 

Enumeration elements = PhoneNumberType. elements ( ); 

PhoneNumberType pt; 

while (elements.hasMoreElements( )) { 

pt = (PhoneNumberType)elements.nextElement( ); 

System.out.pruit3n(pttoString( )); 

} 

} 

public String toString( ) { 
return typeld; 

} 

} » 



35 



This type partition is used by PhoneNumber. See main( ) 
for uncommenting a line that demonstrates the type safety 
protection through the use of static final and private con- 
structors. 



package Party; 

import java.io.PrintStream; 

import java.io.StringWriter; 

public class PhoneNumber 

{ 

private PhoneNumberType phoneNumberType; 

private String areaCode; 

private String prefix; 

private String suffix; 

public PhoneNumber( ) { 

areaCode - null; 

prefix - null; 

suffix - null; 

} 

public PhoneNumber(String aPhoneNumber) 
{ 

parsePhoneNumber(aPhoneNumber); 
setPhoneNumberType(PhoneNumberType.HOME); 

} 

public PhoncNumber(String anAreaCode, String aPrefix, String aSuflSx) 
{ 

areaCode = anAreaCode; 
prefix - aPrefix; 
suffix - aSuffix; 

} 

public String areaCode( ) 
{ 

return areaCode; 

} 
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public void areaCode(String anAreaCode) 
{ 



areaCode - anAreaCode; 



} 



public boolean equals(String aPhoneNumber) 
{ 

PhoneNumber tempPhoneNumber = new 
PhoneNumber(aPhoneNumber); 
10 return equals(temp PhoneNumber); 
} 

public boolean equals (Phone Number aPhoneNumber) 
{ 

if (areaCode( ) «= null && aPhoneNumber.areaCode( ) != null || 
aPhoneNumber. areaCode( ) = null && areaCode( ) !- null) 
15 return false; 

if (areaCode( ) != null) 
{ 

if (areaCodef ).equals(aPhoneNumber.areaCode( )) && 
pre fix ( ).equals(aPhoneNumber.prefix( )) && 

suffix ( ).equals(aPhoneNumber.sufEx( ))) 
20 return true; 

else 

return false; 

} 

if (prefix( ). equal s(aPhoneNumber.prefix( )) && 
sufEx( ).equals(aPhoneNumber.suffIx( ))) 
25 return true; 

else 

return false; 

} 

public static void main(String argv[ J) 
30 { 

JU PhoneNumber aPhoneNumber; 

System. out.println ('Testing construction & comparison!"); 
if(argv.length == 0) 

.{ 

System. out.println(Test with no area code-no masks"); 
aPhoneNumber = new PhoneNumber('*5579203"); 
aPhoneNumber.setPhoneNumberType (PhoneNumberType. FAX); 
System.out. println(a PhoneNumber. toString( )); 
System.out. print ln("Test with area code- no masks"); 
aPhoneNumber = new PhoneNumber("20 65572039"); 
aPhoneNumber.setPhoneNumberType (PhoneNumberType. WORK); 
System. out. println(aPhoneNumbcr.toString( )); 
System. out.println("Test with normal masks"); 
aPhoneNumber - new PhoneNumber("(206)5 5 7-3920"); 
a PhoneNumber.se tPhoneNumbeiType(PhoneNumberType. PAGER); 
S ystem.out .printl n(aPhone Number.toS tring( )); 
System.out.println("Test equality 5578215 557-8215"); 
4 j PhoneNumber tempi = new PhoneNumber( w 5578215"); 

' templ.setPhoneNumberType(PhoneNumberType.CELL); 
PhoneNumber temp2 - new PhoneNumber ("5 57-8215"); 
temp2.setPhoneNumberType(PhoneNumberType.CELL); 
//temp2.setPhoneNumberTypc(new PhoneNumberType (6, 
"TOT')); // enum type safety w/private ctor 
50 System. out .println( tempi); 

System.out.println(temp2); 
S ystem.out .printing tempi — temp2: " + 
templ.equals(temp2)); 
return; 
}etse{ 

55 aPhoneNumber - new Phone Number(argv[0]), 

System.out.println(aPhoneNumbcr.toString( )); 

} 

} 

private void parsePhoneNumberfString aPhoneNumber) 
{ 

60 StringBuffer aStr = new StringBuffer(aPhoneNumber.length( )); 
int i - 0; 
do 

if (Character, is Digit (aPhoneNumber.charAt(i))) 
aStr.append(aPhoneNumbe r.char At(i)) ; 
while (i++ < aPhoneNumber.length( ) - 1); 
Siring tempString ■> new String(aStr); 
if (aStr.length( ) — 7) 



65 
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{ 

prcfix(tcmpString.substring(0, 3)); 
suffixftempString.substringp, 7)); 
return; 

} 

areaCode(tempString.substring(0, 3)); 
prefu(tempString.substrLng(3, 6)); 
suffix (tempS tring.substring (6, 10)); 

} 

public String prefix( ) 

{ 

return prefix; 

> 

public void prefix(String aPrefix) 

{ 

prefix = aPrefix; 

} 

/" 

*This method was created by a SmartGuide. 

*@param sw String Writer 

*/ 

public void printOn (String Writer sw) { 

sw. write (((area Code != null || areaCode «* "") ? ("(" + areaCode( ) + 

")"): "")); 

sw. write (this. prefix( )); 

sw. write ("-"); 

sw. write (this. suffix( )); 

return; 

} 

public void setPhoneNumberType(PhoneNumberType pnt) { 
phoneNumberType - pnt; 

} 

public String suffix( ) 

{ 

return suffix; 

} 

public void suffix(String aSuffix) 
{ 

suffix - aSufHx; 

} 

public String toStringf ) 
{ 

return new String(phoneNumberType.toString( ) +": * + ((areaCode 
!-null || areaCode -= ) ? ("("+ areaCode ( ) + ")"): + prefix( ) + + 
suffix( )); 
} 
} 



Alternatives 

Smalltalk allows for grouping logical constants in Pool- 
Dictionaries as in TextConstants. This is simply a global 
dictionary with key value pairs that simplifies and improves 
readability by using well understood names like "Space" and 
"Tab". However, they are global variables and they are not 
automatically recreated when you file in code that depends 
on them. 

When constants are implemented in a class within Small- 
talk accessors must be used. There is no real language notion 
of final or const in Smalltalk that would allow for accessing 
member variables. 

Communications Services Patterns (1008) 

An original tenet of component-based design has been 
simplified distribution of functionality. According to the 
original argument, up-front definition of component bound- 
aries and their interfaces would simplify the configuration of 
functionality on the network. Even though component-based 
design has simplified distribution, it has not guaranteed 
success. Networks introduce performance issues and failure 
conditions that didn't exist in non-distributed solutions. If a 
solution is to be successful, these issues can't be ignored. 

Each pattern in this section addresses a difficulty associ- 
ated with distributed computing. Every pattern reflects a 
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problem and a solution to issues encountered by other 
development teams. 

Legacy systems running on mainframes, Unix boxes, etc. 
are an important part of today's client projects. The majority 

5 of today's clients have existing computer systems that 
cannot be easily rewritten or ignored. Integration of these 
older systems with the newly developed applications is often 
imperative to the success of the project. Any newly devel- 
oped components must leverage the existing functionality on 

10 these Legacy systems. The Legacy Wrapper pattern 
addresses this problem. It describes a common pattern for 
tackling the integration issues associated with reusing func- 
tionality from existing systems. 

Server-side components implement services for use by the 

35 Clients in an application. These components should clearly 
specify the interfaces and services they provide, but how 
should they make them available? A well-known central 
service, e.g., a Name Service or Trader Service can be used 
to make the interfaces available to all Clients, but is that 

20 always warranted or prudent? Should every Client have 
access to every service? The Locally Addressable Interface 
(LAI) and Globally Addressable Interface (GAI) patterns 
describe two approaches to this problem. 

The performance characteristics of remote components 

25 are very different from "in process" components. The cost of 
requesting and transmitting data between remote compo- 
nents is much higher and should be considered in a distrib- 
uted solution. As a result, distributed solutions often call for 
communication patterns that improve upon the performance 
aspects most important to the system. The Structure Based 
Communication pattern addresses the "cbattiness" associ- 
ated with distributed applications. It helps reduce network 
load and increases system response time. The Paging Com- 
munication pattern addresses the common need to retrieve 
and display large lists of data. It shows how incremental 
fetching can be used to provide much better perceived 
responsiveness in GUI based applications. 
The cost of locating a remote service and establishing a 

4Q connection to that service can also be a costly endeavor. The 
Refreshable Proxy Pool pattern describes a robust and 
efficient way to minimize this "lookup" activity. 

Most recent component-based systems use middleware 
such as CORBA, DCOM or Java RMI to specify the 

4 5 interfaces provided by components and the associated data 
types. However, such middleware is not always available, or 
directly applicable. In such situations the Stream Based 
Communication pattern, or one of its descendants, the Fixed 
Format Stream and Self Describing Stream patterns might 

5 o be applicable. These patterns describe different techniques 
for efficiently streaming data between processes. While they 
all share a common solution to a common problem, the 
solutions present different tradeoffs between implementation 
simplicity, performance and flexibility. 

55 A Null value represents the "empty set" and is an impor- 
tant value in distributed component solutions. 

Some languages, such as Java, support Null as a specific 
value, whereas other languages do not (e.g., C++ which uses 
zero and context to determine Null). This language mis- 

60 match can cause problems in distributed systems that use 
more than one language. The Null Structure pattern 
describes this problem and proposes a solution. 
Fixed Format Stream 

FIG. 65 illustrates a flowchart for a method 6500 for 

65 providing a fixed formal stream-based communication sys- 
tem. In operation 6502, a sending fixed format contract on 
interface code is defined for a sending system. A receiving 
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fixed format contract on interface code is also defined for a 
receiving system. A message to be sent from the sending 
system to the receiving system is translated in operation 
6504 based on the sending fixed format contract. The 
message is then sent from the sending system and subse- 
quently received by the receiving system in operations 6506 
and 6508. The message received by the receiving system is 
then translated based on the receiving fixed format contract 
in operation 6510. 

In one embodiment of the present invention, information 
in the translated message received by the receiving system 
may also be stored in a relational database. In one aspect, the 
fixed format contracts may be included in meta-data of the 
message. Also, in another aspect, the message may include 
an indication of a version thereof. 

In one situation, one of the systems is an object -based 
system and one of the systems may be a non-object -based 
system. In another situation, both of the systems are may be 
object -based systems. In a third situation, both of the sys- 
tems may be non-object-based systems. 

Stream-based communication is a very effective pattern 
for relaying data, data structures, and meta-data. Meta-data 
is information about the data like data structure, data types, 
etc. using a shared, generic format. How can the message 
format be shared between systems so as to create the most 
straightforward and best performing stream-based mecha- 
nism? 

Often, it is determined that a stream-based communica- 
tion mechanism should be used to transport information 
between systems. Stream-based communication is a pattern 
where information is transported from one system to another 
using a simple stream and a shared format to relay the data 
structure and meta-data information. 

FIG. 66 illustrates two systems 6600 communicating via 
a stream -based communication 6602 and using a common 
generic format to relay the meta-data information. 

However, when implementing Stream-based 
Communication, a number of factors influence the method 
for enabling each system with a "shared format.** The 
"shared format" provides the meta-data information needed 
to interpret the raw data in a stream. This shared format is 
like a secret decoder ring for systems sending and receiving 
messages. It allows the systems to convert structured data 
(objects, strings, etc.) into raw data and raw data back into 
structured data. This is needed to transmit the structured data 
across the network. 

On many projects, the following factors influence the 
details of communicating using a stream. 

High performance — System performance is always a 
factor, but sometimes it is one of the most important 
factors in a system. 
Short development time — The system must be opera- 
tional in the shortest possible timeframe. 
Stable information characteristics — In some solutions, the 
data and the structure of the data are stable and unlikely 
to change. 

In cases like this, how can one optimize the benefits of 
stream -based communication and implement only the most 
basic capabilities that one requires? 

Therefore, use the Fixed Format Stream pattern to create 
a stream-based message that uses fixed format contracts to 
share the formatting information and meta-data between 
systems. 

Fixed format contracts are maps that contain the meta- 
data information such as the data structure, data separators, 
data types, attribute names, etc. They describe how to 
translate Fixed Format messages onto a stream and off of a 
stream. 



78,068 Bl 

210 

FIG. 67 illustrates an example of a Fixed Format message 
6700 associated with the fixed format stream patterns. The 
location and size of each attribute in the message is fixed and 
known at design time. In the example below, it is known that 

5 the command will be in bytes 1-9, the first name will be in 
bytes 10-29, the last name in bytes 29-49, etc. This infor- 
mation (meta-data) is used by the Fixed Format contracts to 
convert Fixed Format messages from data structures to raw 
data and back again. 

3Q FIG. 68 depicts the complete Fixed Format Stream pattern 
associated with the fixed format stream patterns. A data 
structure on System A 6800 is translated to a Fixed Format 
message (raw data) using a Fixed Format contract. The 
message is put in the stream 6802 and sent to System B 
6804. System B 6804 receives the Fixed Format Message 

15 (raw data) and uses its Fixed Format contract to recreate the 
data structure. The same process works in reverse when 
System B 6804 responds to the message request. 
Benefits 

Performance. Because there is no time spent on look-ups 
20 or dynamic translation of the message, performance is 
better than with other variations of Stream-Based Com- 
munication. 

Small Message Size. Each Fixed Format message con- 
tains only data to be sent to the other system. These 

25 messages contain no meta-data and are smaller than 
those in Self-Describing Streams. 
Simplicity. Translating and parsing information onto and 
off of the stream is straightforward and easier than with 
the other variations of Stream-Based Communication. 

30 The behaviors for the Fixed Format Streaming are 
contained in the fixed format contracts on the interfaces 
of the sending and receiving systems and thus easy to 
find. 

Object Friendly. This pattern is very straightforward to 
35 implement in object based systems. The objects contain 
the fixed format contracts and manage the translation 
and parsing onto the stream. These objects can access 
their own private behaviors which makes the interface 
much simpler. 

40 Implementing this pattern is very straightforward. Define 
corresponding fixed format contracts on the interface code 
of both the sending and receiving systems. FIG. 69 illus- 
trates fixed format contracts 6900 containing meta-data 
information for translating structured data onto and off of a 

45 stream. 

In non-object systems, define a fixed format contract on 
the parsing interface module of the sending system. The 
interfacing module on the sending system can use the 
contract as a map for how to translate and write the data onto 

50 the stream. Define a corresponding fixed format contract on 
the interface modules of the receiving system. The interface 
module on the receiving system can use the contract to read 
and translate the data off of the stream. 

In object-based systems, make each object responsible for 

55 its own fixed format contract. Using this contract, each 
object is able to retrieve and parse its attribute values onto 
a stream as strings (streamOn) and each object class should 
be able to parse attributes off of a stream and put them into 
a new instance of an object (streamOff). Also, it is good 

60 practice to include the version of the format within the 
stream so that concurrent format versions can be accommo- 
dated in the design. 

Below is a pseudo-code example of an object-based 
system communicating with a non-object system using 

65 stream-based communication and a fixed format contract. 
FIG. 70 illustrates a Customer object 7000 in an object- 
based system 7002 streaming itself into a stream 7004, the 



05/06/2004, EAST version: 1.4.1 



US 6,578,068 Bl 



211 



stream being sent to a non-object system 7006, this stream 
being read and the data inserted into a relational database 
7008. 

1. The CustomerObject with attributes name, sex, and age 
has a method "streamOn: aStream." It is invoked with an 
empty stream as the argument 'aStream'. The Customer- 
Object "streamOn:" method goes through each of the 
object's attributes and parses each values as a string onto 
the stream. 

The fixed format contract here is embodied in the order 
that this method parses the attributes onto the stream. A 
pseudo-code example in Java is the following: Note- 
Assume that "asString( )" converts the receiver to a 
string and that "padWithSpaces( )" pads the string with 
spaces and makes the string the length specified. 



/** Stream my attribute values on aStream "*/ 
public void streamOn (OutputStream aStream) 

{ 

aStream.write (this .getName 0- asStrin gO-pad WithSpaces (1 0)) ; 

aStream.write(this.getSex0.asString0.padWithSpaces(7)); 

aStream.write(trus.getAge0.asString().padWithSpaces(3)); 



20 



25 



2. The stream is then put into a message communication 
mechanism like MQSeries or MessageQ and sent to the 
non-object system. 

3. Once at the non-object system, interface code reads 
through the stream, parses the values off of the stream, 
converts them to the appropriate types if required, and 
puts them in a copybook with the appropriate structure. In 
this example, the fixed format contract is embodied in the 
structure and type of the WS -SHARED- FORMAT- 
CUSTOMER working-storage copybook. Refer to the 
pseudo-COBOL example below. 



DATA DIVISION. 
FD FILE-STREAM-IN 

RECORD CONTAINS 20 CHARACTERS 

WORKING-STORAGE SECTION. 

THIS COPYBOOK CONTAINS THE COMMON FORMAT OF 
THE 

CUSTOMER IN THE DATA STRUCTURE AND DATATYPES 
01 WS-COMMON-FORMAT-CUSTOMER 
03 WS-COMMON- FORMAT- NAME PIC X(10). 

03 WS-COMMON-FORMAT-SEX PIC X(7). 

03 WS-COMMON- FORMAT- AGE PIC 999. 

*** THIS COPYBOOK IS THIS SYSTEMS VIEW OF A CUSTOMER 
01 WS-CUSTOMER 

03 WS-NAME PIC X(10). 

03 WS-AGE PIC 999. 

03 WS-SEX PIC X(10). 

PROCEDURE DIVISION. 

OPEN THE FILE STREAM AND PUT THE CONTENTS IN THE 
— WS-COMMON-FORMAT-CUSTOMER COPYBOOK. 
OPEN FILE- STREAM- IN 

READ FILE-STREAM-IN INTO WS-COMMON-FORMAT- 
CUSTOMER 

AT- END CLOSE FILE-STREAM-IN 
END- READ. 

••* MOVE THE VALUES INTO FROM THE COMMON FORMAT 
INTO 
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THE WS-CUSTOMER VARIABLES. 

MOVE WS-COMMON-FORMAT-SEX TO WS-SEX. 

5 MOVE WS-COMMON-FORMAT-AGE TO WS-AGE. 

MOVE WS-COMMON- FOR MAT- NAME TO WS-NAME. 

CALL A SQL MODULE TO SAVE THIS INFORMATION IN 
THE 

"* RELATIONAL DATABASE 
10 CALL "SAVE-CUSTOMER-IN-DATABASE" USING WS- 
CUSTOMER. 

STOP-RUN. 



Conversely, a stream could be created by a non-object 
system (or another object-based system for that matter) and 
sent to one's object-based system. In this case, Customer- 
Object could use a "streamOff: aStream" method and instan- 
tiate a new instance of an aCustomerObject and populate it 
with the appropriate attribute values. 

Eagle Architecture Framework: Uses Stream Based Com- 
munication in a number of ways. First of all, it uses it 
to embed tracing information in CORBA distributed 
requests. Second of all, it is used to replicate state 
between fault-tolerant services. 
MCI: Invoice Development Workbench. This workbench 
helps MCI create error- free invoice definitions for the 
various Local Bells. Stream-based communication was 
used as part of an efficient, lightweight persistence 
30 mechanism. 

Java Serialization: This is a Java defined fixed format for 

streaming objects. 
Object Request Brokers (ORBs) that use CORBA, 
DCOM, or Java Remote Method Invocation (RMI) — 
35 ORBs that use one of these standards implement this 
pattern. They define an Interface Definition Language 
(IDL) that is the format or contract of the stream and 
use stream-based communication as the communica- 
tion medium. 
40 Collaborations 

Stream -based Communication. This is the parent pattern 
to Fixed Format Stream. In this pattern, information is 
transmitted using a simple stream and a shared, generic 
format. The Fixed Format Stream is a more specific imple- 
45 mentation of Stream-Based Communication. 

Structure Based Communication — This pattern uses a 
Fixed Format Stream to transmit data structure between 
systems. It is often used to obtain data from a Server for 
display in a Client UI. 
50 Bridge (from the Gamma book Design Patterns) describes 
a way to de -couple an abstraction from its implementation 
so that the two can vary independently. The Bridge pattern 
is often used to define collaborations between a business 
object and a format object while decoupling the business 
55 object from its specific stream format. 

Abstract Factory (from the Gamma book Design Patterns) 
is a pattern for creating families of related classes. This 
could be used with the Bridge pattern to retrieve the format 
dynamically based on non-static information. 
60 Alternatives 

Self-Describing Stream. This pattern is a specific imple- 
mentation of Stream-Based communication where the mes- 
saging format is parameterised and stored on the stream. A 
message language is used to read and write the format of the 
65 message from the stream. 

Downloadable Format Stream — This pattern is a specific 
implementation of Stream-Based communication where the 
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messaging format is stored at a central location and is 
downloaded by the communicating parties when needed. 
Globally Addressable Interface 

FIG. 71 illustrates a flowchart for a method 7100 for 
delivering service via a globally addressable interface. A 
plurality of interfaces are provided in operation 7102 and 
access is allowed to a plurality of different sets of services 
from each of the interfaces in operation 7104. Each interface 
has a unique set of services associated therewith. Each of the 
interfaces is named in operation 7106 with a name indicative 
of the unique set of services associated therewith. The names 
of the interfaces are then broadcast to a plurality of systems 
requiring service in operation 7108. 

The access may be allowed via structured -based commu- 
nication. As another option, the names may be broadcasted 
using a naming service. Also, the naming service may 
provide the systems requiring service with a location of the 
interface on a network. In addition, the systems requiring 
service may be capable of looking-up the interfaces using 
the naming service. 

In a client-server environment, a client makes requests of 
services on a Server. In such an environment, how might a 
Server expose its services for use by one or more clients? 

In a typical two or three-tiered client-server application, 
the services are maintained away from the users (Client) on 
separate Server machines. Whenever a user needs to use a 
service, the user must send a request across the network to 
the Server machine. 

Before a client can utilize a service, it must find the 
service. If the client is unable to find the service, it can't ever 
use it, FIG. 72 depicts a client 7200 that is unable to find the 
services provided by a server 7202 via a network 7204. 

The client could look for services in a naming service. 
However, if the services don't exist in the lookup or naming 
service, the client still can't find and use the service. 

Therefore, use a Globally Addressable Interface to expose 
services to all available clients. 

A Globally Addressable Interface builds upon the Inter- 
face pattern and the Naming pattern. When implementing a 
Globally Addressable Interface, a Server's operations are 
bundled into logical groups using the Interface pattern. 

FIG, 73 illustrates the grouping of services 7302 using 
interfaces 7304. 

For example, all the operations for accessing and viewing 
customer information (Get Customer, Get Customer 
Address, etc.) could be bundled into one interface. All the 
operations for changing customer information (Change 
Customer, Address, Change phone number, etc.) might be 
bundled into another interface. Keep in mind, this is an 
example "bundling" of operations and not the definitive 
method for bundling operations. 

Once all the operations have been grouped into an 
interface, the interface is given a name appropriate to the 
operations it bundles. Then the interfaces are announced 
using the Naming pattern. The Naming pattern enables 
registration of interfaces in a globally available naming 
service. FIG. 74 illustrates a customer server 7400 publicly 
announcing its interfaces 7402. 

Until that time, a client can't find the operations and can't 
use them. Thus, the Server must use the Lookup or Naming 
pattern to register its interfaces (not methods). Once the 
interfaces have been registered with such a service, any 
client can go to the Naming Service, locate an interface, and 
access an operation in that interface. 
Benefits 

Public Addressability — Every Globally Addressable 
Interface is publicly available for use by any client. As 
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a result, any Client can find these interfaces and access 
these operations. 
Stateless Load Balancing. Globally Addressable Inter- 
faces are generally implemented for stateless Servers. 
5 When Stateless Servers are used, it is a lot easier to 
balance the incoming load. Since state or context is 
always passed into the Server, any call can be directed 
to any Server that supports a particular operation. If one 
is busy, the Client can be forwarded on to the next one. 
1Q The following is a message trace diagram depicting the 
interactions associated with a Globally Addressable Inter- 
face. 

The Message Trace diagrams depict a common Client- 
Server scenario. A client requests customer data from a 
Server. The Server finds the data in a database and forwards 
15 it back to the client. The Client can then display the data in 
a User Interface for a user. 

The scenario was broken into two message trace dia- 
grams. The first message trace sets the stage for the second. 
In the first message trace, the Server registers two Globally 
20 Addressable Interfaces with a Naming Service. The Client 
then "looks-up" an interface and establishes a connection to 
that interface. 
Assumptions 

CORBA ORB connects Client and Server 
25 CORBA Naming Service used to lookup GAIs 

FIG. 75 illustrates a method 7500 including the register- 
ing and then locating of a globally addressable interface. 
Collaborations 

la. "Bind" the interface name (Update Interface) with it's 
30 Remote Object Reference (network location) in a Naming 

Service. This will allow clients to "lookup" the interface. 

Once the Interface is registered in the Naming Service, it 

has become globally addressable. Any client can find the 

interface and access a operation. 
35 lb. "Bind" the second interface in the same manner as the 

first. 

2. The client instantiates a Proxy (Browsing Interface Proxy) 
to the Browsing Interface on the Customer Server. 

3. The Proxy "looks up" the network location of the Brows- 
40 ing Interface. It makes a request of the Naming Service. 

It requests the network location of the Browsing Interface. 

4. The Naming Service returns the Remote Object Reference 
(network location) for the Browsing Interface. The Proxy 
now has all the information it needs to access an operation 

45 on the Browsing Interface. 

The second message trace builds upon the first. In this 
message trace diagram, the Client calls the Server through a 
Globally Addressable Interface. The server finds the appro- 
priate customer data and returns it to the Client. The Client 

50 can then display it in the UI. 

FIG. 76 illustrates the present invention using a method 
7600 wherein a globally addressable interface is used to 
obtain data from a server. The steps associated with the 
method 7600 of FIG. 76 will now be set forth. 

55 Collaborations 

5. The Client asks the Browsing Interface Proxy for the data 
associated with customer 1234. 

6. The Browsing Interface Proxy forwards the request across 
the network to the Browsing Interface. 

60 7. Same as 6. 

8. The request is forwarded to the Customer Server. The 
Customer Server requests the customer data from the 
Database. 

9. The Database returns the customer data for Customer 
65 1234. 

10. The Customer Server creates a structure and populates it 
with the customer data. 
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11. The Customer Structure is forwarded through the Brows- 
ing Interface, across the network and back to the Brows- 
ing Interface Proxy. 

12. The Browsing Interface Proxy forwards the Customer 
Structure to the Client. The Client can now display the 
data in a UI for a user. 

IDL Interfaces and Structures 

The following IDL defines the two Interfaces and Struc- 
tures used in the message trace diagram s above. 



module CustomcrScrvcr 
{ 

// CORBA IDL for the Update Interface 
interface CustomerUpdatelnterface 
{ 

void changeCustomer( long an Id, 
commonDefs::CustomerStructure aCustomer); 

void change Address (long anld, 
commonDefs::AddressStructure aNewAddress); 

string changePhoneNumber(long anld, string 
aNewPhoneNumber); 

}; 

// CORBA DDL for the Browsing Interface 
interface CustomerBrowsinglnterface 
{ 

commonDefs::CustomerStructure getCustomer(long anld); 
commonDefs::AddressStructure getAddress(long anld); 
string getPhoncNumber(long anld); 

}; 

}; 

// This module defines the structures passed through the two // customer 
interfaces. 

module commoaDefs 
{ 

struct AddressStructure 
{ 

string street; 
string city; 
string state; 
string zip; 

string phoneNumber; 

}; 

struct CustomerStructure 

< 

string id; 
string status; 
string firstName; 
string lastName; 

}; 

}; 

Sample Code 

The following is some Sample Java code for the Skeleton portion. 
//Pass all requests on to the Component for processing 
public CustomerStructure getCustomer( 
String aCustomertd) 
{ 

CustomerComponent aCustomerComp - this.getComponent( ); 
retu ra(aCustome rCo mp .ge tCustomer(aCusto me rid)); 

} 

//Pass all requests on to the Component for processing 

public String getPhone(String aCustomertd) 

{ 



} 

The next snippet of code is for the Customer Component (Server). The 
interface delegates the processing to the component. 

// Get the Customer's data and return it. 

public CustomerStructure getCustomer(String aCustomerld) 

{ 

// Go to the database and get the 
// customer with the appropriate ED 
Customer sCustomer - . . . 
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-continued 

// Create a structure and populate it with the 

// customer data retrieved from the DB. 
5 CustomerStructure a CustomerStructure = new 

Customers tructure( ); 

aCustomerStructure.id = aCustomer.getId( ); 

aCus tome rS true ture.status = aCustomer.getStatus( ); 

aCustomerStructure. firstName = 
aCustomer.getFirstName( ); 
10 aCustomerStructure.lastName 
aCustomer.getLastName( ); 

return (aCustomerStructure); 

} 

public String getPhone(String aCustomerld) 
{ 

15 

} 

public AddressStructure getAddress(String aCustomerld) 

{ 

20 } ' 

Additional Considerations 

The GAI class is actually represented by two different 
25 classes (and the Component itself). Each GAI is made up of 
a Proxy and a Skeleton. The Proxy represents the interface 
on a Client while the Skeleton represents the interface on a 
Server. 

Collaborations 

30 Proxy — Hie proxy pattern is generally used to commu- 
nicate from a Client to a Globally Addressable Interface on 
a Server. 

Structure Based Communication — Often times, a client 
needs to display data in a UI for a user (e.g. Customer 

35 Information, Order Information, etc.). When communicating 
through a Globally Addressable Interface, this data is trans- 
mitted from the Server to the Client using Structure Based 
Communication. 

Load Balancing — When a number of servers implement 

40 the same Globally Addressable Interface, the Load Balanc- 
ing pattern is used to balance Client requests between these 
Servers. 

Proxy Pool — The Proxy Pool pattern helps balance the 

cost of instantiating Remote Proxies and retaining Proxy 
45 "freshness." The Proxy Pool pattern can be used to create a 

pool of Proxies to Globally Addressable Interfaces, 

Locally Addressable Interface — Locally Addressable 

Interfaces are private interfaces that aren't easily located. 

Generally, a well-known interface (like a Globally Addres- 
50 sable Interface) is used to find a LAI. A Client easily find and 

access a service on a Globally Addressable Interfaces and 

request a reference to a Locally Addressable Interface in 

return 

Interface — The Interface pattern defines methods or func- 
55 tions or services rather than implementation. The Interface 

pattern is expanded upon by the Globally Addressable 

Interface pattern. 

Naming — The Naming pattern describes a pattern for 

registering and finding services or objects etc. where they 
60 can be easily found in an application. The Naming pattern is 

often used to register Globally Addressable Interfaces so 

they are publicly available 

Alternatives 

Locally Addressable Interface — The Locally Addressable 
65 Interface pattern is both a collaborating and alternative 
pattern. It can be used to retrieve information from Servers 
instead of Globally Addressable Interface. 
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Legacy Wrapper 

FIG. 77 illustrates a flowchart for a method 7700 for 
affording access to a legacy system. A plurality of compo- 
nents coupled to a client via a component integration archi- 
tecture are provided for servicing the client in operation 5 
7702. A legacy system is interconnected to the client via the 
integration architecture using a legacy wrapper in operation 
7704. In operation 7706, the legacy system and the client are 
interfaced via the legacy wrapper by communicating with 
the client by way of a first protocol and by communicating 10 
with the legacy system by way of a second protocol. 

As an option, the legacy wrapper may include a legacy 
wrapper component coupled to a component adapter which, 
in turn, may be coupled to a legacy adapter via a legacy 
integration architecture. In this aspect, the legacy adapter as 
may also coupled to the legacy system. As another option, 
the component adapter may also reformat call parameters of 
the message into an acceptable format for the legacy system. 

As an additional option for this aspect, the legacy wrapper 
component may also include a pure legacy wrapper com- 20 
ponent. As even a further option to this aspect, the legacy 
wrapper component may include a hybrid legacy wrapper 
component. Also, the interfacing may further include: send- 
ing a message from the client to the legacy wrapper com- 
ponent via the component integration architecture; sending 25 
the message via the component adapter to the legacy inte- 
gration architecture; forwarding the message to the legacy 
adapter; formatting the message to match an application 
program interface (API) of the legacy system; executing 
calls on the legacy system based on the formatted message; 30 
executing function of the calls and returning results to the 
legacy adapter, legacy integration architecture, component 
adapter, and legacy wrapper component which reformats the 
results; and forwarding the reformatted results to the client 
via the component integration architecture. 35 

Legacy systems pose a unique situation for developers of 
component-based solutions. Commonly hosted on 
mainframes, Legacy Systems often communicate through 
proprietary protocols, have no standard data or process APIs 
and don't integrate easily with component based systems. 40 
How does a developer access a Legacy System in a 
component-based solution? 

A legacy system is an existing system that does not 
conform to the technology, architecture and standards of the 
current project. A large IBM 3090 Mainframe running 45 
programs to calculate automobile insurance rates is an 
example of a Legacy System. It is large, very important to 
an insurance company, and runs on older, proprietary hard- 
ware. 

Legacy Systems generally utilize different communica- 50 
tion protocols than those used by newly developed compo- 
nent systems. As a result, communicating between a newly 
developed component and a Legacy System is very difficult. 

FIG. 78 depicts the communication difficulties associated 
with Legacy Systems 7800 attempting to communicate with 55 
a client 7802 via a component integration architecture 7804. 
The newly developed application (client and components) 
communicates through a different protocol than the existing 
Legacy System. FIG. 78 illustrates heterogeneous Interfaces 
from Components. 60 

Legacy Systems are critical to an organization and usually 
represent a significant investment. They are tightly con- 
trolled to reduce the incidence of system failures and clients 
may be unwilling or unable to replace these older systems. 

New applications could be developed on the mainframe 65 
system, however, this generally is not considered strategic 
and takes a lot of time and effort. Organizations want to add 
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new functionality (new processes) without investing in the 
old legacy system. 

As a result, the current Legacy Systems represent signifi- 
cant investments, are often crucial to a business and aren't 
easily replaced. Investing in new Legacy applications isn't 
practical or strategic and Legacy Systems can't communi- 
cate with newer componentized systems. 

Therefore, the component-based solution should use a 
Legacy Wrapper to communicate with the existing Legacy 
Systems. The Legacy Wrapper is a component built to adapt 
the front end of a legacy system to the rest of the component - 
based solution. 

This solution encapsulates the concerns of a Legacy 
System away from the new application. It allows other 
components in the solution to communicate with the legacy 
component in the exact same manner as the rest of the 
component-based solution. Further, this solution can also be 
used to partition the existing Legacy System functionality. 
FIG. 79 illustrates homogenous interfaces from components 
7900 which rectify the problems with Legacy Systems 7901 
attempting to communicate with a client 7902 via a com- 
ponent integration architecture 7904. 
Benefits 

Reuse. The Legacy Wrapper pattern allows reuse of an 
existing Legacy System. New component applications 
can be developed that leverage the rich store of busi- 
ness processes and data that already exist on the Legacy 
System. 

Migration. Allows for slower migration of functionality 
from the Mainframe to components. By continuing to 
use the functionality of the existing legacy system, the 
immediate need to build the same functionality in a 
pure component-based solution is lessened. 
Encapsulation. Provides a separation of concerns between 
the new system and the Legacy System. By encapsu- 
lating the Legacy System, the impact of host changes is 
largely limited to the Legacy Wrapper. 
The implementation of legacy Wrapper is usually very 
specific to the type of Legacy System it is integrating. The 
implementation in this section attempts to give a high level 
overview of the components of typical legacy systems. 

FIG. 80 shows how a Legacy Component is integrated 
into a component-based model 8000. 

The upper part of FIG. 80 depicts the main units 8002 of 
a component-based solution. The lower part of the picture 
depicts the Legacy Component 8004 in greater details. 

The following is a description of the participants in the 
upper portion of FIG. 80. 

The Client (8006) is the application running on the user's 
machine. It is responsible for UI presentation, local 
business objects, and communication using client resi- 
dent proxies. 

The Component Integration Architecture (8008) is the 
component that allows clients to communicate and 
remotely invoke functions on the server components. 
Typically this is based on some middleware standard 
(e.g., CORBAor MTS). 
The Components (8010) in this FIG. 80 represents the 
server components. These are the business entity com- 
ponents and the business process components. They are 
invoked from the Client via client proxies. 
From the outside, the Legacy Component 8004 looks 
identical to any other component. However, internally is 
performs a very specialized function. 

The lower part of FIG. 80 expands the Legacy Component 
8004. The expansion shows the individual elements, which 
comprise the Legacy Component 8004. These elements are: 
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The Legacy Wrapper Component (8012) is responsible high level, it should provide some insight as to how the 

for presenting the same functionality provided by the Legacy Component functions and how it invokes work on 

legacy system to the rest of the component-based the legacy system. 

solution. Other components of the new component- p rom tne example of FIG. 83, the following steps are 

based solution will interact and communicate with this 5 shown: 

component. Although this component wraps the exist- L The Clieal component wants to invoke some 
ing legacy system, it should behave as any other functionality, which is located on the legacy system. The 
component in the newer solution. clieQt a meS sage via the Component Integration 
The Component Adapter (8014) is a custom component Architecture (e.g. ORB) on the way to the Legacy Wrap- 
responsible for the translation from the Legacy Wrap- 1Q Component 

U ?TT n ationiffi 2 ' 7116 Com P on6nt Integrate Architecture (e.g. ORB) 

g y gr . forwards the call to the appropriate Legacy Wrapper 

The Legacy Integration Architecture (8016) is responsible Comnonent 

for sending and receiving messages between the server 3 ^ u y w Com t sends lhe cal , via the 

and host machines. This architecture is usually based « * aj . . .i_ > i * *• a i_ * 

on some specific communication implementation. 15 p° mp ™ Adapter t0 r ^ gacy ^^on Archilcc- 

Examples of this include message queues and common ^ ™> en ^ Component Adapter reformats 

databases accessible by both legacy systems and the call parameters into an acceptable format for the 

component-based solutions. Legacy System. 

Hie Legacy Adapter (8018) is a custom component 4 ' ^Legacy Integration Architecture ^receives a call for the 

responsible for translation from the particular imple- 20 host-based Legacy application and forwards it to the 

mentation of the Legacy Integration Architecture to the Legacy Adapter. 

Legacy System. 5. The Legacy Adapter receives the message from the 

The Legacy System (8020) is the existing system that will Legacy Integration Architecture and formats it to match 

be accessed by the newer component-based solution. tne ^ l of tne Legacy System. It makes the appropriate 

Changes to the Legacy System should be minimized 25 calls 00 the Legacy System. The Legacy System executes 

when accommodating the new component -based solu- , the function and returns the results to the Legacy Adapter 

t j 0D 6. The Legacy Adapter receives the results and returns them 

The application on the host is responsible for translating t0 the Legacy Integration Architecture, 

messages between the Legacy Integration Architecture and 7 - ^ Legacy Integration Architecture receives the result 

the Legacy System. For example, the application must know 30 and forwards it to the Legacy Wrapper Server Component 

how to format calls to CICS appropriately, as well as through the Component Adapter. 

interpret results and reformat them in a way appropriate for 8 < The Legacy Wrapper Component receives the result, 

the Legacy Wrapper server component. reformats the parameters for the component system and 

The degree to which the wrapper components are spe- forwards it to the Component Integration Architecture, 

cialized to partition the functionality of the existing legacy 35 9 - Finallv > Component Interaction Architecture receives the 

system can vary. result and forwards it to the Client 

Pure Legacy Wrapper Component Collaborations 

One type is the Pure Legacy Wrapper Component. This Message Queued Legacy Integration is a specific imple- 

component simply adapts the legacy system to the new mentation of this pattern. It uses message queues as the 

component-based solution. No new business processes are 40 le S ac y integration architecture. 

added. The interface methods on the Legacy Wrapper Com- Adapter (from the Gamma book Design Patterns) 
ponent "pass through" to the legacy system, as shown in describes at a more abstract level how to convert the 
FIG. 81. FIG. 81 illustrates Legacy Wrapper Components of interface of a class into another interface that clients expect, 
a Pure Legacy Wrapper Component including a Legacy Proxy— This pattern is documented in Design Patterns by 
Wrapper Component 8112, a Component Adapter 8114, a 45 Gamma, Helm, Johnson and Vlissides. The proxy pattern is 
Legacy Integration Architecture 8116, a Legacy Adapter often used 1° communicate with server components in a 
8118, and a Legacy System 8120. distributed environment. The Proxy would be used to corn- 
Hybrid Legacy Wrapper Component municate across the Component Integration Architecture to 

Another type of Legacy Wrapper Component is the a Legacy Wrapper. 

Hybrid component. FIG. 82 illustrates a Hybrid Component 50 Alternatives 

type of Legacy Wrapper Component. As shown, the hybrid Screen Scraping is a more specialized version of legacy 

includes a Legacy Wrapper Component 8212, a Component wrapping. It describes how to convert a user interface to that 

Adapter 8214, a Legacy Integration Architecture 8216, a of tne ssrwT ( ie > the le S ac y svstem in lhis case )- In this 

Legacy Adapter 8218, and a Legacy System 8220. solution, the host-based application generates 3270 type 

It is a mix of legacy system adapter and some new 55 screens and then passes them to CICS. The advantage of this 

business processes built in a single component. Some of the solution is that it is non-invasive to CICS and reacts as if it 

interfaces 8222 of the wrapper component 8212 "pass were just another terminal interacting with CICS. This may 

through" to the legacy system, while other interfaces com- be necessary with legacy systems which must be leveraged, 

municate with objects, which may in turn call the legacy but can not be modified and provide no common API set. 

system. 60 Locally Addressable Interface 

There are potentially more variations, including use of an FIG * 84 Urates a flowchart for a method 8400 for for 

Event Service to allow the mainframe to initiate work from delivering service via a locally addressable interface. In 

the wrapper components. operation 8402, a plurality of globally addressable interfaces 

and a plurality of locally addressable interfaces are provided. 

tAAMrLt 65 A Ccess ^ allowed to a plurality of different sets of services 

FIG. 83 shows an abstract example of the control flow in from each of the globally addressable interfaces and the 

a Legacy Component. Although, the example is at a very locally addressable interface in operation 8404. Each inter- 
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face has a unique set of services associated therewith. In 
operation 8406, the globally addressable interfaces are reg- 
istered in a naming service for facilitating access thereto. 
Use of the locally addressable interfaces is permitted only 
via the globally addressable interfaces or another locally 5 
addressable interface in operation 8408. 

In an option, the use of the locally addressable interfaces 
may be facilitated by structured-based communication. As 
another option, the access may be allowed via a customer 
interface proxy, a customer server and a database of the 3Q 
globally addressable interface. 

In one embodiment, a request may be received by the 
customer interface proxy for a reference to one of the locally 
addressable interfaces. The request may then be forwarded 
across a network to the database of a server of the globally 
addressable interface. Also, data from the database may be 15 
returned in response to the request. Additionally, an object 
may be instantiated and populated it with the data by the 
server of the globally addressable interface. The object may 
also be associated with one of the locally addressable 
interfaces. Also, the locally addressable interface may be 20 
forwarded to the globally addressable interface. As even a 
further option, a reference may be forwarded to the locally 
addressable interface across the network and to the customer 
interface proxy. In addition, the use of the customer interface 
proxy may be also used to access the locally addressable 2 $ 
interface across the network. 

In a client-server environment, a client makes requests of 
Services on a Server. In such an environment, how might a 
Server expose its services for use to a client in a tightly 
controlled manner? 30 

Quite often a component wants tight control over the 
visibility of its interfaces or does not have a need to make its 
interfaces widely available. Examples of such situations 
include: 

Security — A component may provide multiple interfaces, 35 
some of which have sensitive operations that should not 
be exposed to all clients. For example, an insurance 
company's customer service desktop application gets 
full access to all interfaces and services on a Customer 
component, but an Independent Agent application has 40 
restricted access to services. 

Interface Design — From a design standpoint it may make 
sense to limit access to some interfaces. For example, 
a system operations interface might allow clients to 
query Server components for the number of requests 45 
being serviced, or disable future requests on a particular 
Server. In this type of situation, it's best to limit access 
to the appropriate user group. In this case, the opera- 
tions tools specifically designed for administering a 
system. 50 

Large number of interfaces — If the component design 
calls for a large number of interface instances (objects), 
then it would be detrimental to use the GAI pattern. The 
sheer number of interfaces could overcrowd and over- 
burden the Naming or Trader service. The Naming or 55 
Trader service would slow down as it searched its large 
list of entries. Additionally, the system would slow 
down as every client attempted to access the Naming or 
Trader service for every interface. 

Thus, it's sometimes best to keep interfaces with limited 60 
appeal out of a Naming or Trader Service. 

No need — If a particular interface or service only bas one 
client, why bother registering it globally? It doesn't make 
sense and causes additional administration. 

FIG. 85 illustrates Problems with Globally Addressable 65 
Interfaces in a system 8500 including clients 8502 and 
servers 8504 with a plurality of interfaces 8506. 
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The last couple of points are quite common for stateful 
components. The above samples clearly do not call for the 
GAI pattern — an alternative manner of making interfaces 
available to clients is required. 

Therefore, the Locally Addressable Interface pattern 
should be used to control access to interfaces in an efficient 
manner. 

FIG. 86 illustrates the manner in which the present 
invention uses a Locally Addressable Interface 8600 to hide 
functionality and lessen the load on the Naming or Trading 
Service 8602. 

All components maintain a Globally Addressable Inter- 
face 8604 This interface is registered with a Naming or 
Trader service 8602 and can have any of its services 
accessed by any client on the network. The services on a 
GAI 8604 are generally stateless and potentially shared by 
many clients. 

Locally Addressable Interfaces 8600 are not registered 
with a Naming or Trading service 8602 and can only be 
obtained through a Globally Addressable Interface 8604 or 
another Locally Addressable Interface 8600. 

FIG. 87 illustrates the manner in which the present 
invention obtains a Locally Addressable Interface 8700. 

Globally Addressable Interface 8702 services typically 
are used to obtain Locally Addressable Interfaces 8700 by 
providing some key information to the service, trigger 
global changes to all of the component's member objects, or 
to obtain component-maintained data that is not represented 
by a Locally Addressable Interface 8700. 

It is important to note that member business objects are 
never directly exposed to the client but, rather, communi- 
cated with through a component interface (global or local). 
This allows for changes to be made to the internal structure 
of the component without disturbing the way a client inter- 
faces with the component. Encapsulation is preserved. 
Benefits 

Tight control. Servers providing LAIs have full control to 
determine which clients will receive them. This control 
could, for example, be based on client type, access 
rights or server load. 

No central bottleneck. The pattern does not rely on a 
centralized service to hand out interfaces. This leads to 
a scalable architecture that can handle many interface 
instances. 

Useful for stateful components. Stateful components 
often contain many objects, each accessed through a 
separate interface instance. The LAI pattern is very 
useful in such circumstances. 
Complex server side relationships. The LAI pattern is 
better for managing complex object relationships than 
most alternatives. If an object is associated with a lot of 
other objects (an order holds a customer and an address 
and a line item etc.), it isn't practical to copy all of the 
objects to the client. 
The following is a message trace diagram depicting the 
interactions associated with a Locally Addressable Interface. 

The Message Trace diagrams depict a common Client - 
Server scenario. The Client would like to interact with a 
specific Customer on the Server. The client requests a 
Locally Addressable Interface to a Customer Object on the 
Server and communicates with that object. 

The scenario was broken into two message trace dia- 
grams. The first message trace sets the stage for the second. 
In the first message trace, the Server registers a Globally 
Addressable Interface with the Naming Service. The Glo- 
bally Addressable Interface will be used to get the Locally 
Addressable Interface. 
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Assumptions 

CORBA ORB connects Client and Server 

CORBA Naming Service used to lookup GAIs 

FIG. 88 illustrates the method in which the present 

invention registers and then locates a Globally Addressable 

Interface 8800. The various steps shown in FIG. 88 are set 

forth hereinbelow. 

Collaborations 

la. "Bind" the interface name (Customer Interface) with it's 
Remote Object Reference (network location) in a Naming 
Service. This will allow clients to "lookup" the interface. 
Once the Interface is registered in the Naming Service, it 
has become globally addressable. Any client can find the 
interface and access a operation. 

2. The client instantiates a Proxy (Customer Interface Proxy) 
to the Customer Interface on the Customer Server. 

3. The Proxy "looks up" the network location of the Cus- 
tomer Interface. It makes a request of the Naming Service. 
It requests the network location of the Customer Interface. 

4. The Naming Service returns the Remote Object Reference 
(network location) for the Customer Interface. The Proxy 
now has all the information it needs to access an operation 
on the Customer Interface. 

The second message trace builds upon the first. In this 
message trace diagram, the Client calls the Server through a 
Globally Addressable Interface. The server finds the appro- 
priate customer data and instantiates an object with the data. 
A Locally Addressable Interface to the specific Customer 
object is then returned to the Client. 

The Client can then directly access the specific Client 
through the Locally Addressable Interface. 

FIG. 89 ilustrates the manner in which the present inven- 
tion uses a Globally Addressable Interface 8900 to obtain a 
Locally Addressable Interface 8902 to a specific Customer 
Object 8904, Note the steps set forth below. 
Collaborations 

5. The Client asks the Customer Interface Proxy for a 
reference to a Locally Addressable Interface for Cusomer 
1234. 

6. The Customer Interface Proxy forwards the request across 
the network to the Customer Interface. 

7. The request is forwarded to the Customer Server. The 
Customer Server requests the customer data from the 
Database. 

8. The Database returns the customer data for Customer 
1234. 

9. The Customer Server creates instantiates an object and 
populates it with the customer data. The Customer object 
is associated with a Locally Addressable Interface 
(Update Interface). 

10. The Locally Addressable Interface is forwarded to the 
Customer Interface. 

11. The Customer Interface forwards a reference to the 
Locally Addressable Interface, across the network and 
back to the Customer Interface Proxy. 

12. The Customer Interface Proxy instantiates an Update 
Interface Proxy with the reference to the Update Interface. 

13. The Customer Interface Proxy forwards the Update 
Interface Proxy to the Client. 

14. The Client sends a new address for the customer to the 
Update Interface Proxy. 

15. The Update Interface Proxy forwards the information 
across the network to the Update Interface. 

16. The Update Interface forwards the new address to the 
Customer Object. The Customer Object updates its 
address based upon the new information. 
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Collaborations 

Proxy — The proxy pattern is generally used to commu- 
nicate from a Client to a Locally Addressable Interface on a 
Server. 

5 Interface — The Interface pattern defines methods or func- 
tions or services rather than implementation. The Interface 
pattern is expanded upon by the Locally Addressable Inter- 
face pattern. 

Globally Addressable Interface — Locally Addressable 
10 Interfaces are private interfaces that aren't easily located. 
Generally, a well-known interface (like a Globally Addres- 
sable Interface) is used to find a LAI. A Client can easily find 
and access a service on a Globally Addressable Interface and 
request a reference to a Locally Addressable Interface in 
15 return. 

Structured Based Communications — Often times, a client 
needs to display data in a UI for a user (e.g. Customer 
Information, Order Information, etc.). When communicating 
through a Locally Addressable Interface, this data is trans- 
20 mitted from the Server to the Client using Structure Based 
Communication. 
Alternatives 

Globally Addressable Interface. The Globally Address- 
able Interface pattern is both a collaborating and alternative 
25 pattern. It can be used to retrieve information from Servers 
instead of Locally Addressable Interface — the right choice 
will depend on the context. 
Null Structure 

FIG. 90 illustrates a flowchart for a method 9000 for 

30 communicating a null value. A query is first communicated 
in operation 9002 from a first system to a second system to 
determine whether a data structure is a null value. Next, in 
operation 9004, a response to the query is received from the 
second system indicating whether the data structure is a null 

35 value. A request for the data structure is sent from the first 
system to the second system in operation 9006 only if the 
response indicates that the data structure is not a null value. 
Subsequently, the data structure is received from the second 
system in operation 9008. 

40 As one option, the response may be a Boolean indication. 
As another option, the response may be determined based on 
an attribute of the data structure. As a further option, the data 
structure may represent a set of a plurality of values. Also, 
the first system may, optionally, be a client and the second 

45 system is a server. 

When transmitting data across a network between a client 
and server application, the middleware's "type system" does 
not always support null values. How can a remote service 
send or receive null values over a communications medium 

50 that does not support them? 

It is expected that distributed Business Components will 
collaborate with other Business Components via some sort 
of communications medium. Communications between 
components is not usually handled by the components 

55 themselves but rather by some communications middleware 
(like an object request broker, or ORB). 

A "null" value is a frequently used value in object-based 
systems. A "null" represents the empty set. It is often 
returned from a service that is unable to find the requested 

60 elements or is used as an optional parameter in a distributed 
service. For example, a Client might request all the custom- 
ers with a last name of "Smith." If no Customers exist with 
a last name of "Smith," a "null" value would be returned. 
Some legacy systems return -999 or 0 when no data 

65 exists. This is not an ideal solution as the system is using 
data to represent non-data. What if -999 or 0 are valid 
responses to a request? Instead, a "null" could be used to 
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better represent this case. A "null" value provides extra 
flexibility since a specific data value need not be reserved to 
represent the empty set. 

However, middleware cannot represent every data type 
that exists in every language. Since middleware is "language 
neutral", it can only represent the least common denomina- 
tor of every language accessible via the middleware. Due to 
this constraint, "null's" often can not be represented in 
middleware. FIG. 91 illustrates the problem associated with 
sending a NULL across many types of middleware 9100. 

A system should be able to take advantage of this impor- 
tant value and use middleware that may not support it. 

Therefore, use the Null Structure pattern to pass a struc- 
ture with an isNull attribute across the middleware. Unlike 
a "null", a structure can be passed across the middleware. 

FIG, 92 ilustrates the manner in which the present inven- 
tion passes a "null" structure across the middleware 9200, 

The extra attribute on the structure then determines 
whether or not the structure represents a "null" value. The 
structure can be queried to determine whether or not it 
represents a "null" value. FIG. 93 depicts conversations 
9300 with a "null" data structure 9302. FIG. 94 depicts 
conversations 9400 with a non-"null" data structure 9402. 

The isNull attribute could be added as shown in the IDL 
example below. 



structure contract 
{ 

boolean isNull; 
long buyerldentifier; 
long seller Identifier, 
double rate; 

}; 



Benefits 

Flexibility. This pattern allows for "null" values to be 
utilized by distributed components. 

The following example assumes a CORBA implementa- 
tion. In order to pass Null Structures across an ORB, a 
structure must be defined in the ORB's interface definition 
language (IDL). The following IDL defines a structure that 
will represent an Integer or a "null." 



struct Common Integer 
{ 

long value; 
boolean isNull; 

} 



In the code that prepares the data to be sent over the ORB, 
a check of the data is made and the structure is populated 
appropriately. If it is null, the isNull flag is set, otherwise it 
is cleared. Refer to the following code example: 



public Commonlnteger convertIntegerForORB(Integer anlnteger) 

Common Integer integerStructure - new CommonlntegerO; 

ififanlnteger -» null) 

{ 

integerStructure.isNull - true; 

} 
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-continued 

else 

{ 

-> integerStructure.isNull false; 

integerStructure. value = anlnteger.int Value 0; 

} 

return integerStructure; 
} 

10 

The receiving code that obtains the data from the ORB 
does the same conversion in reverse as shown in the method 
below: 

15 

public Integer convertIntegerFromORB(CommonInteger 

a nlntegerStru cture) 

{ 

Integer anlnteger = null; 

if (anlntegerStructure.isNull false) // structure not null 
anlnteger « new Inleger(anIntegerStructure .value); 

} 

return anlnteger, 

} 

25 

Collaborations 

Proxy. A Proxy is a placeholder that can accept requests 

meant for another object. This is typically used in distributed 

systems when one component wants to send a request to 
30 another. Thus, a proxy is often used to make requests of 

servers that may return null structures. 

Client-Server. Client-Server is a type of architecture that 

separates the Client portion of an application from the 

business logic or database portion of an application. When 
35 implementing a Client-Server application, the Client and 

Server often communicate across a middleware (like 

CORBA) that doesn't support "nulls." 

Alternatives 

Invalid Value. Determine an "invalid value" for each data 

40 type in the particular application. Return the "invalid value" 
when ever a null should be returned. 
Paging Communication 

FIG. 95 illustrates a flowchart for a method 9500 for 
transmitting data from a server to a client via pages. In 

45 operation 9502, pages of data sets are built from data in a 
database of a server. Upon receipt of a first request from a 
client for the data in the database of the server in operation 
9504, a first one of the pages of the data sets is sent to the 
client over a network in response to the first request in 

50 operation 9506. When a second request from the client for 
the data in the database of the server is received in operation 
9508, a second one of the pages of the data sets is then 
transmitted to the client over the network in response to the 
second request in operation 9510. 

55 The second request may be sent to the server with an 
identifier of a last entry of the first page. Also, a size of the 
data sets of the pages may be defined dynamically. As an 
option, the pages may be displayed by the client upon receipt 
from the server. Also, a size of the data sets of each of the 

60 pages may be determined based on a user interface of the 
client. As another option, a size of the data sets of each of 
the pages may be determined based on an amount of data 
capable of being displayed at once by the client. 

In a client-server environment, a client often needs to 

65 display or process a long list of data. Finding and transmit- 
ting this list of data can take a long lime and negatively 
impact the user's response time. How can a client and server 
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interact to improve the user's response time when retrieving 
a large list of data? 

The speed with which a UI can respond to a "user 
initiated" request is important. This is generally called the 
UI response time and is an important attribute of every 
application. FIG. 96 depicts the response time 9600 for a 
User Interface 9602 to display a list of customers in a list box 
9604. 

Users expect an "acceptable" level of UI response in their 
applications. Applications that don't meet this criteria, will 
not be successful. 

Many UIs allow users to query databases for lists of data. 
In FIG. 96, for example, the user clicks the "Get Customers" 
button to initiate a database query. The query will retrieve 
every customer from the database and the UI will display the 
customers in a list box. The user can then scroll through the 
data and select a particular entry for further investigation. 

FIG. 97 shows a request that returns a large amount of 
data. As shown, in a three-tiered client-server environment, 
each query must travel from the client UI 9700, across a 
network 9702, to a Server 9704, and eventually to a Data- 
base 9706. Then, the result of the query must travel all the 
way back to the client. 

When the query results in a large amount of data, the time 
to search the database and return the data across a network 
can become prohibitive. As a result, the UI response time 
will quickly degrade to an unacceptable level. 

To make things worse, the average user only looks at half 
of the data returned from the database. The user is just as 
likely to find their data in the first half of the list as the 
second half of the list. As a result, the user may wait a long 
time for data that is not used. 

FIG. 98 shows a graphical depiction of a paging commu- 
nication pattern 9800. 

Therefore, provide Paging Communication between the 
client and server tiers of an application. Paging Communi- 
cation describes a pattern for transmitting a large amount of 
data while maintaining an acceptable UI response level. 

Rather than send all of the data at one time, a subset or 
"page" 9802 of data is transmitted. When the client needs 
more data, another "page" 9802 of data is transmitted. This 
continues until the client has seen enough data or all the data 
has been transmitted. 
Benefits 

More Responsive UI. This pattern improves upon the 
user's response time. The server only retrieves and 
transmits a "page" of data at a time. This is a lot faster 
than retrieving and transmitting all of the data at one 
time. The pattern breaks-up the total search and trans- 
mission time into smaller page-sized chunks. This 
greatly improves upon the user's perceived perfor- 
mance. 

Additionally, the Server searches the database for a 
"page" of data at a time until the user finds what they 
are looking for. As a result, unless the needed data is in 
the last page of data, the search is limited to a portion 
of the total search. 

Configurable Page Size. The page size can be "tuned" to 
best fit the application. As a result, the page size can be 
altered to best fit a particular network, application 
design, etc. 

Stateless Servers. The paging mechanism can be managed 
from the client-side requestor. Thus, this pattern can be 
used with stateless servers just as easily as with statefiil 
servers. 

UI Tunable. The page size can be changed to match a 
particular User Interface. 
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List Box Friendly. A list box can only display a limited 
amount of data at one time. As a result, it isn't as 
important to have all of the data immediately available 
for the list box. The List box can display a page of data, 
and then request additional pages of data as the user 
scrolls through the list. 
Scenario: A user is searching for a particular customer. 
The user doesn't remember the exact name of the customer, 
but the user believes they will recognize the name when they 
see it. Thus, the user requests a list of all customers. 
Technical Parameters 
Static Page Size«4 

List Box can only display 2 lines of data at a time. 

FIG. 99 illustrates a message trace diagram showing the 
interactions between a Client 9900 and a Server 9902 using 
Paging Communication to satisfy the previously mentioned 
scenario. 
Definitions 

Starting Key 

The Starting Key is the initial starting point for the 
search. The database will begin searching for data 
(customers in the message trace above) at the Starl- 
ing Key. An example starting key could be "A*". 
Last Found Key 

The Last Found Key is used to request subsequent 
pages of data from the Server and the database. The 
"last found key" defines the starting point for the 
next data request. The Server will begin searching 
for data at the "last found key" and continue until it 
has retrieved a full "page" of information. 

When all of the data has been retrieved from the Server 
and Database, the Last Found Key is left blank. This 
notifies the Client that all the data has been sent. 
Intermediate Page 

An intermediate "page" is returned for every request 
but the last. When a client receives an intermediate 
page and a "last found key", the client knows more 
"pages" of data exist on the server. 

In order to obtain an intermediate "page," a "last found 
key" must be passed from the client to the server. 
When the Server has retrieved a full "page" of data, 
the new "last found key" is saved. It is then passed 
back with the intermediate "page." The new "last 
found key" defines the starting point for the next data 
request. 
Last Page 

When the Server has retrieved all of the data meeting 
the search criteria, the Server builds the last "page." 
When the last page is returned to the client, the "last 
found key" is left blank. This notifies the client the 
search is complete and no more data matching the 
search exists on the Server. Note that the last page is 
usually smaller than the other pages. 
Empty Page 

When no data are selected from the search criteria, the 

server builds an empty page signaling to the client no 

more data exist on the server. 
Static or Dynamic Page size 

The page size can be defined statically or dynamically. 

The message trace diagram in FIG. 99 depicts a static 

page size. 

If you'd like a dynamic page size, the client must pass 
an additional parameter with each request to the 
Server. The additional parameter would be the page 
size. 

The steps associated with FIG. 99 will now be set forth. 
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Collaborations 

1. The user "clicks" the "Get Customers" button on the User 
Interface. The Client UI makes a getAllCustomers request 
of the Server and passes a Starting Key as a parameter. 
Since the user wants to view all of the customers, a 
Starting Key of spaces is used. Message sent« 
getAllCustomers(" ") 

2. The Server receives the request from the Client. The 
Server realizes the Starting Key is blank and knows this 
is a new request. Thus, the Server requests first four 
customers (the page size) from the database. 

3. The database returns the first four customers (Albert 
Abraham, Ned Abraham, Sally Abraham and Alice Allen) 
and a "Last Found Key" ("Alice Allen") to the Server. The 
"Last Found Key" denotes the last entry found during the 
search. It will be used for subsequent searches. 

4. The Server builds a page with the four customers retrieved 
from the database. The Server returns the page and the 
Last Found Key to the Client. 

Page Type=Intermediate 

Page="Albert Abraham", "Ned Abraham", "Sally Abra- 
ham" & "Alice Allen" 
lastFoundKey*" Alice Allen" 

The Client receives the "page" of data. The Client sends 
the data to a UI List Box for viewing by the user. The User 
can see the first two customers (Albert Abraham, Ned 
Abraham). 

The User clicks the "scroll down" arrow twice and can 
now see two additional customer (Sally Abraham, Alice 
Allen). 

5. The User clicks the "scroll down" arrow again. No more 
data exists on the Client so the Client must request another 
page from the server. The Client UI makes a getAllCus- 
tomers request of the Server and passes the Last Found 
Key of Alice Allen. Message sent«getAllCustomers 
("Alice Allen"); 

6. The Server receives the request from the Client. The 
Server requests the next four customers (page size) after 
Alice Allen. Message sent«getPageOfcustomer(" Alice 
Allen") 

7. The database returns the next four customers (Jason Allen, 
Fred Allen, Sam Allen & Zack Allen) and a "Last Found 
Key" ("Zack Allen") to the Server. 

8. The Server builds a page with the four customers retrieved 
form the database. The Server returns the page and the 
Last Found Key to the Client. 

Page Type»Intermediate 

Page="Jason Allen", "Fred Allen", "Same Allen" & 

"Zack Allen" 
lastFoundKey="Zack Allen" 

The Client receives the "page" of data. The Client sends 
the data to a UI List Box for viewing by the user. The User 
can see the first two customers and one new customer (Alice 
Allen, Jason Allen). 

The User can now scroll through the next three customers. 
When scrolling past customer Zack Allen, the Client will 
request another page of data from the Server. It will follow 
the same basic pattern as described in steps 5-9. 

Eventually, the end of the list of Customer will be 
reached. 

n-3. Once again, the client clicks the "scroll down" arrow 
and no more customers exist on the client. The Client 
must request another page from the server. The Client 
UI makes a getAllCustomers request of the Server and 
passes the Last Found Key of Jim Ziegler. Message 
sent»getAllCustomers("Jim Ziegler"); 
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n-2. The Server receives the request from the Client. The 
Server requests the next four customers (page size) 
after Jim Ziegler. Message sent«getPageOfcustomer 
("Jim Ziegler") 

5 n-1. The database can only find two more customers. The 
database returns the final two customers (Sam Ziegler 
and Ziggy Ziegler) and no Last Found Key. 
n. The Server builds a page with the two remaining 
customers retrieved from the database. The Server 

10 returns the page and the blank Last Found Key to the 
Client. 

Page Type = Last Page 

Page "Sam Ziegler", "Ziggy Ziegler" 

lastFoundKeyo"" 
15 The Client receives the final "page" of data. The Client 
sends the data to a UI List Box for viewing by the user. The 
User can see the following two customers (Jim Ziegler, Sam 
Ziegler). 

The User clicks the "scroll down" arrow once and can 
20 now see the final two customers (Sam Ziegler, Ziggy 

Ziegler) in the List Box. 
Subsequent "clicks" on the scroll down arrow no longer 

request data from the Server. The Client knows (due to the 

blank last found key) that it has already received all of the 
25 available data. 

Additional details 

Context isn't generally stored on the Server when imple- 
menting Paging Communication. As a result, it is important 

to request a minimum collection of data from the server. 
30 Most of the relational database are using a count mechanism 

that defines the maximum number of data to search. That 

will minimize CPU and memory usage. 

As explained in the example, page size may be adapted to 

the client requirements, however that does not mean the 
35 page size must exactly fit the widget size. Ideally the client 

application will anticipate future user actions and request 

more than one page. 

Collaborations 

Proxy — The Proxy pattern is often used to communicate 
40 between Clients and Servers in a distributed environment. A 

Proxy is often used to make requests for a "page" of data 

from a Server. 

Interface Control Model — The I CM pattern addresses the 

separation of the Interface (Viewing portion) from the 
45 Control from the Model (the data portion) in an application. 

Paging Communication is often used when implementing 

this separation of functionality. A user through the Interface 

uses the pattern to retrieve large lists of data from the Model 

for viewing. 

50 Globally Addressable Interface — Globally Addressable 
Interfaces are often used to obtain a Page of data from a 
Server for display in a Client UI. 
Alternatives 

Paging with Server Caching — This pattern builds upon 
55 the Paging Communication pattern. Rather than querying 
the database for a "page" of information, the Server would 
retrieve all of the data at one time. Then the Server would 
pass the data to the Client one page at a time. 
Refreshable Proxy Pool 
60 FIG. 100 illustrates a flowchart for a method 10000 for 
interfacing a naming service and a client with the naming 
service allowing access to a plurality of different sets of 
services from a plurality of globally addressable interfaces. 
In operation 10002, the naming service calls for receiving 
65 locations of the global addressable interfaces. As a result of 
the calls, proxies are generated based on the received 
locations of the global addressable interfaces in operation 
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10004. The proxies are received in an allocation queue 
where the proxies are then allocated in a proxy pool (see 
operations 10006 and 10008). Access to the proxies in the 
proxy pool is allowed for identifying the location of one of 
the global addressable interfaces in response to a request 
received from the client in operation 100010. 

The proxy pool may employ load balancing. As another 
option, the proxies in the proxy pool may be renewed based 
on an age thereof. As a third option, a handle may interface 
the proxy pool and the client. This handle may additionally 
interface a plurality of the proxy pools and the client. 

In distributed systems with many clients, it is important to 
establish connections with remote servers in an efficient 
manner. In a manner where clients evenly utilize the avail- 
able servers. How can this be performed in a consistent 
manner for all clients? 

In production systems it is quite common for long-lived 
clients to "stay up" for days and interact with a collection of 
different servers. Oftentimes, a client process will establish 
connections to the same type of server a bunch of times 
during its lifetime. The lifetimes of the client and its servers 
are often different as a result of server maintenance and 
failures. However, such failures should have minimal impact 
on the client. Clients in such systems usually retrieve a 
Globally Addressable Interface (GAI) from a naming or 
Trader Service (see GAI Pattern). 

A GAI retrieved by a client will usually go through three 
phases: 1) Initial retrieval of a GAI from the Trader Service 
that is subsequently wrapped up in a proxy, 2) Invocations 
of businesses functions supported by the GAI and 3) Release 
of the GAI proxy. This often means a long-lived client will 
repeatedly ask the Trader Service for the same type of 
interface during its lifetime. 

FIG. 101 illustrates repeated requests to the Trader Ser- 
vice 10100 for the same interfaces are neither efficient nor 
necessary 

Repeatedly requesting the same interface from a Trader 
Service is neither efficient or necessary. However, the Trader 
Service does maintain load balancing information and allo- 
cates the least busy interface at any given time. Thus, some 
value exists in repeated reallocation. 

Therefore, use a Refreshable Proxy Pool mechanism that 
standardizes the usage, allocation and replenishment of 
proxies in a client's pool. Initially, the Proxy Pool will 
allocate a bunch of Proxies to remote services using some 
sort of a Lookup Service (e.g. Trader Service, Naming 
Service). The Proxy Pool will hold onto these Proxies and 
allocate them to Clients as they need them. When the client 
asks the Proxy Pool for a proxy, the pool will hand out a new 
Proxy. 

FIG. 102 illustrates how a pool 10200 can be created that 
reuses GAI proxies. 

In order to balance the system load evenly, the Proxy Pool 
should implement a Load Balancing approach (e.g. Round 
Robin) for handing out proxies within the pool. 

Each proxy in the pool has a "retirement age." The 
"retirement age" determines the time to refresh a given 
Proxy. When a Proxy reaches its retirement age, it is taken 
out of the pool and replaced with a freshly allocated Proxy. 
This ensures the Proxy Pool is refreshed regularly with new 
GAIs retrieved from the Trader Service. The retirement 
mechanism helps dynamically balance the systems load. 
Benefits 

Performance. Establishing connections to servers will 
take less time because clients will go to the trading 
service less often. 

Balanced Load. This ensures all clients are implementing 
the same strategy for utilizing available servers. 



Standard. One single approach to pooling increases main- 
tainability and predictability across the enterprise and 
decreases confusion. 

Ease of use. Client developers do not have to design and 
5 implement their own version of pooling. 

Maintenance. This mechanism allows for centralized 
development. When a bug is found it can be fixed and 
distributed to all build centers. 
10 Dynamic. Client threads will not have to worry about 
allocating retired or bad proxies. 

Robustness. By pooling GAI location information, clients 
are less susceptible to Trader Service failure. This is 
because the Proxy Pool can operate using the GAIs it 
15 has information on for as long as those references main 
valid. 

The Proxy Pool should be packaged and distributed to 
client developers so that it is non-intrusive and easy for them 
to use. 

20 Parameters such as pool size and retirement age should be 
configurable. 

The client thread using the proxy should not pay a penalty 
for pooling or allocation. 

The pool should recover gracefully from server failure. 
25 The pool should recover gracefully from Trader Service 
failure. 

FIG. 103 illustrates the implementation of a Refreshable 
Proxy Pool 10300. The Refreshable Proxy Pool is based on 
a pool-queue approach. In this design, the pool holds allo- 

30 cated proxies 10302 while the queue allocates and replen- 
ishes the pool with proxies. To handle the allocation and 
replenishment, a worker or allocation thread 10304 runs on 
the queue and makes calls to the Trader Services as needed. 
There can be numerous proxy pools, but this implemen- 

35 tation supports typed pools Using C++ templates, i.e., each 
pool will only contain proxies of one type. This allows the 
client to create a class that is passed to the proxy pool and 
supports client specific properties in the pool such as pool 
size, retirement age, etc. Also, due to synchronization issues 

40 with the rest of the architecture, there can be only one 
allocation queue. 

Clients who wish to use a pooled proxy will create a 
handle as a wrapper. This handle wrapper takes care of the 
problems associated with sharing resources across threads 

45 such as lazy initialization, reference counting, allocation, 
and de-allocation. 

Handles are classes that abstract the users away from the 
implementation. Handles are generally stack based and exist 
for the lifetime of a method invocation or an object. The 

50 handle destructor insures that the underlying proxy is deref- 
erenced. 

Suggested Classes 

FIG. 104 illustrates the class relationships between the 
patterns primary classes. 



Class 



60 



Description 



PooledProxy 
(10402) 

ProxyPool 
(10404) 



65 



This is the base class for the pooled proxy. It 
actually acts as a wrapper for a Proxy and maintains 
all usage and reference counting information. 
This is the proxy pool, where clients go to retrieve a 
proxy. It should be thread-safe in that multiple 
threads are automatically synchronized. This pool 
should only contain valid proxies that have been 
allocated by the Allocation Pool. When a proxy is 
requested, the usage count is incremented. After the 
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Class 



Description 



"usage" passes retirement age, the proxy is remove 
from the pool and placed back into the allocation 
pool. 

This is the pool that actually does the proxy 
allocation. This pool is populated with unallocated 
proxies and a "reader" thread will allocate them. 
Since there will only be one, this class should be 
implemented as a Singleton. This pool however can 
allocate proxies of any type. 

This is the Handle that clients should use to manage 
pooled proxies. The handles must use a 
static__cast<T> (C++ template) to retrieve the correct 
proxy. T is defined by a client template instantiation, 
and assumes the client knows exactly what type of 
proxy the pool is actually holding. Clients must take 
care to assure that pools only contain proxies of one 
type. 



AllocationPool 
(10406) 



Proxy Handle<T> 
(10408) 



10 



15 



Collaborations 20 

Globally Addressable Interface — This is a pattern for 
making interfaces publicly available. Distributed connec- 
tions to Globally Addressable Interfaces can be pooled using 
the Refreshable Proxy Pooling pattern. 

Proxy — This pattern is documented in the book "Design 25 
Patterns" by Gamma, Helm, Johnson and Vlissides. The 
proxy pattern is often used to communicate with server 
components in a distributed environment. Proxies are pooled 
using the Refreshable Proxy Pool pattern. 

Trader — The Trader service defines how distributed archi- 30 
tectures locate components based on the types of services 
they provide. The allocation queue interacts with a Trader 
Service to allocate the correct type of proxy. 

Naming — The Naming Service provides a mapping 
between names and object references. A Naming Service 35 
could be used to store the GAI references that the Refresh- 
able Proxy Pool pattern requires. 
Alternatives 

Single Use — As opposed to pooling connections to a 
remote server a client can request a new connection each 40 
time a GAI is needed. This would work best when a client 
infrequently needs GAIs. 

Proxy Pool — This pattern addresses the pooling of prox- 
ies without periodic refreshing. It is a simpler version of the 
Refreshable Proxy Pool that may be of use when server load 45 
is fairly constant. 
Self-Describing Stream 

FIG. 105 illustrates a flowchart for a method 10500 for 
providing a self-describing stream-based communication 
system. Messages are sent including data between a sending 50 
system and a receiving system in operation 10502. Meta- 
data is attached to the messages being sent between the 
sending system and the receiving system in operation 10504. 
The data of the messages sent from the sending system to the 
receiving system is translated based on the me ta -data in 55 
operation 10506. The meta-data includes a first section that 
identifies a type of object associated with the data and a 
number of attribute descriptors in the data. Also included is 
a second section that includes a series of the attribute 
descriptors defining elements of the data. 60 

As an option, the sending system and receiving system 
may each be equipped with logic for interpreting the meta- 
data of the messages. As another option, the elements may 
be defined in terms of size, type, and name. Versions of the 
present invention include a version where one of the systems 65 
may be an object-based system and one of the systems may 
be a non-object-based system, a version where both of the 



systems may be object-based systems, and even a version 
where both of the systems may be non-object-based sys- 
tems. 

Stream-based communication is a very effective pattern 
for relaying data, data structures, and meta-data. Meta-data 
is information about the data, such as data structure, data 
types, etc. using a shared, generic format. How can the 
message format be shared between systems so as to create 
the most flexible stream -based communication mechanism? 

Often, it is determined that a stream-based communica- 
tion mechanism should be used to transport information 
between systems. Stream-based communication is a pattern 
where information is transported from one system to another 
system using a simple stream and a shared format that relays 
both the data and meta-data information. 

FIG. 106 illustrates two systems 10600 communicating 
via Stream-Based Communication 10602 and using a shared 
generic format to relay the meta-data information. 

However, when implementing Stream-based Communi- 
cation 10602, a number of factors influence the method for 
enabling each system with a "shared format." The "shared 
format" provides the meta-data information needed to inter- 
pret the raw data in a stream. This shared format is like a 
secret decoder ring for systems sending and receiving mes- 
sages. It allows the systems to convert structured data 
(objects, strings, etc.) into raw data and raw data back into 
structured data. This is needed to transmit the structured data 
across the network. 

Many additional factors influence the detailed design of 
this communication mechanism. Some systems support 
volatile and constantly changing object models, data models 
and data structures. In these systems, flexible, de-coupled 
communication is extremely important. 

In a constantly changing system, a statically defined 
"shared format" doesn't work very well. Every change to the 
object model, data model of data structure causes a reimple- 
mentation of the "shared format." Each ^implementation 
results in a redesign, recompile, and retest of the changed 
code. 

FIG. 107 illustrates an object -based system 10700 with a 
frequently changing object model 10702 communicating via 
Stream-Based Communication 10704. 

FIG. 107 depicts a constantly changing system. Initially, 
the object-based system 10700 is designed to send Poodle 
objects through a stream to a non-object system 10702. As 
time passes, the system requirements change. Now, the 
object-based 10700 system must send German Shepherd 
objects through a stream to the non-object system 10702. If 
the "shared format" for converting dog objects to raw data 
is inflexible, this will break the system. 

In cases like this, it would be better to implement a 
communication mechanism or "shared format" that can 
better handle changes to the systems. 

Therefore, use a Self-Describing Stream and create a 
stream that contains message data AND descriptive meta- 
data. Then use a message language to read the formatting 
information and meta-data off of the stream. 

FIG. 108 illustrates a stream-based message that contains 
both message data 10800 and descriptive meta-data 10802. 

FIG. 108 depicts a message sent using a Self-Describing 
Stream. The first 30 bytes contain descriptive meta-data 
10802. This meta-data 10802 describes the formatting of the 
"real" data 10800 in the remainder of the message. It 
describes the data type, attribute names, location in the 
message, etc. of the "real" data 10800 in the message. The 
remaining 70 bytes are the "real" data 10800 transmitted 
between the two systems. 
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Additionally, each system must implement a message 
language. The message language defines the rules for writ- 
ing and interpreting the descriptive meta-data. It describes 
how the meta-data is parametarised and embedded in the 
message. 

These Self-Describing messages usually contain three 
distinct sections: a generic header, an attribute descriptors 
section, and a data section. The header portion contains 
generic information about the message. It contains such 
information as the type of object, the number of attributes 
descriptors, the target environments, etc. The attribute 
descriptors section contains a series of attribute descriptors 
that define the various data elements of the information. The 
number of these attribute descriptors is usually defined in the 
header section. The last section contains only data. 

FIG. 109 illustrates the manner in which a message 
language defines how to parameterise the meta-data 10900 
and put it on the stream. 
Benefits 

Greater Flexibility. Because the information about the 
structure of the data has been parameterised and stored 
as additional data within the message, changes to the 
data structure would have no effect on this interface 
mechanism. This means the interface mechanisms will 
not need to be re-designed/re-built/re-tested/re- 
deployed, etc for each change in meta-data. 
Interfacing systems are better de -coup led. Because the 
message format is embedded in the actual stream, this 
format does not need to be stored or kept in synch 
across different systems. It can be "discovered" at 
run-time when the interface is invoked. 
For object-based systems, the implementation is quite 
straightforward. Simply make each object responsible for 
implementing streaming behaviors based on the format and 
message language. Each object should know how to get and 
parse its attribute values onto a stream as string values 
(streamOn) and each object class should know how to parse 
attributes off of a stream and put these values into a new 
instance of the object (streamOff), 

Below is an example of a Self-Describing stream. It is 
used to stream an object's information from an object -based 
system to a non-object system. 

FIG. 110 illustrates a Customer object 11000 in an object- 
based system 11002 streaming itself into a stream 11004, the 
stream 11004 being sent to a non-object system 11006, this 
stream 11004 being read and the data inserted into a rela- 
tional database 11008. The steps illustrated in FIG. 110 will 
now be set forth. 

1. The Custom erObject with attributes name, sex, and age 
has a method "streamOn: aStream." It is invoked with an 
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empty stream as the argument ' aStream \ The Customer- 
Object "streamOn:" method goes through each of the 
object's attributes and parses each value as a string onto 
the stream. 

In the Java pseudo-code below, the message language 
defines the format of the header, the format of the 
attribute descriptors, and the delimiter used in the 
parsing. 

Note: Assume that "asString( )" converts the receiver to a 
string and that "padWithSpaces( )"pads the string with 
spaces and makes the string the length specified. 



/** Stream my attribute values on aStream **/ 
public void streamOn (Outputs tream aStream) 
{ 

// CREATE THE HEADER 
2Q aStream.write(* CUSTOMER *);//This is a customer object 

aStream.write('003 f ); // with three attributes 

aStream.write('OOr); // this is the format version 

// DESCRIBE EACH ATTRIBUTE 

aStream.write(S tream. Delimiter); 

aStream.write(' NAME '); 
25 aStream.write('STG '); 

aStream.writeCOlO'); 

aStrea m .write (Stream .Delimiter); 

aStrea m.write(' SEX '); 

aStream. write('STG '); 

aStream.write('007'); 
30 aStream.write (Stream. Delimiter); 

aStream.write('AGE '); 

aStream.write('NUM '); 

aStream.write('O03'); 

// WRITE OUT THE ATTRIBUTE VALUES AS DATA 
a Strea m.write(Stream . Delimiter); 
35 aStream.write (this, getName 0 .asString().pad WithSpaces (10)); 

aStrea m . wr ite(this, getSex Q. asStringO. pad WithSpaces (7)) ; 
a Strea m .wr ite(this. getAgeQ .as StringO.pad WithSpa ces(3)) ; 

} 



40 2. The stream is then put into a message communication 
mechanism like MQSeries or MessageQ and sent to the 
non-object system. 
3. Once at the non-object system, interface code reads the 

45 stream, parses the values off, converts and moves the 
values into a copybook with the appropriate structure, and 
saves the information in relational database. A pseudo- 
COBOL example is listed below. In reality, this interface 
code would be more dynamic than depicted in this 
example. 



DATA DIVISION. 
FD FILE-STREAM- IN 

RECORD CONTAINS 100 CHARACTERS 

WORKING-STORAGE SECTION. 

01 WS- FILE-STREAM- IN PIC X(100). 

Ol WS-SHARED-FORMAT-HEARDER 

03 WS-HEADER-OBJECT-TYFE PIC X(10). 

03 WS-HEADER-NUM-OF- ATTRIBUTES PIC X(7). 

03 WS- HEADER- VERSION-OF- FORMAT PIC 999. 
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-continued 



Ol WS-SHARED- FORMAT- ATTRIBUTE 

03 WS- ATTRIBUTE-NAME PIC X(5). 

03 WS- ATTRIBUTE-TYPE PIC X(5). 

03 WS-ATTRIBUTE-SIZE PIC 999. 
Ol TEMP- VARIABLES 

03 WS- INDEX PIC 9999. 

01 WS-CUSTOMER 

03 WS-NAME PIC X(10). 

03 WS-SEX PIC X(7). 

03 WS-AGE PIC 999. 

88 LT- HEADER -SIZE PCX 99 VALUE 20. 

88 LT-ATTRrBUTE- DESCRIPTOR- SIZE PIX X(l) VALUE 14. 

88 LT-DELIMINATOR PIX X(l) VALUE "|". 

88 LT-STRING PIX X(l) VALUE "STG ". 

88 LT- NUMBER PCX X(l) VALUE "NUM " 

PROCEDURE DIVISION. 

*•* OPEN THE FILE STREAM AND READ IT INTO THE 
TEMPORARY *** 

*** VARIABLE WS- FILE-STREAM- IN *** 
OPEN FILE-STREAM-IN. 

READ FILE-STREAM-IN INTO WS- FILE- STREAM- IN 

AT- END CLOSE FILE-STREAM- IN 
END- READ. 

*** MOVE THE HEADER INFORMATION INTO THE HEADER 
COPYBOOK* * * * 

MOVE (WS-FCLE-STREAM-IN FROM ZERO TO LT- HEADER-SIZE) 

TO WS-SHARED-FORMAT-HEADER. 

FIND WHAT BYTE THE DATA STARTS AT AND SET THE 
INDEX **** 

MOVE (LT-ATTR I BUTE-DESCRIPTOR-SIZE * WS-HEADER-NUM- 

OF-ATTRIBTES) 

TO WS-INDEX. 

*** PARSE THE APPROPRIATE OBJECT STRUCTURE OFF OF *** 
*** THE STREAM 

IF WS-HEADER-OBJECT-TYPE EQUALS "CUSTOMER " THEN 
PERFORM 1000-PARSE-CUSTOMER-STREAM THRU 
1000-PARSE-CUSTOMER-STREAM-END. 
ELSE IF WS-HEADER-OBJECT-TYPE EQUALS "EMPLOYEE " 
THEN 

ELSE IF 

ELSE 

*** END THE PROGRAM 

RUN-STOP. 

END-IF. 

1000-PARSE-CUSTOMER-STREAM. 

*** READ WHICH VARIABLE IT IS AND POPULATE THE 

CORRECT*** 

*** VARIABLES 

IF (WS-FILE-STREAM FROM WS-INDEX TO (WS-INDEX +5)) - 

"NAME " 

THEN 

MOVE WS-INDEX TO START-INDEX. 

*** FIND THE DELIMINATOR AFTER THE NAME STRING AND 



*** MOVE THE NAME VALUE INTO THE SEX VARIABLE ***♦ 
PERFORM 

VARYING WS-INDEX 

FROM START-INDEX 

BY 1 

UNTIL (WS-FILE-STREAM-IN AT INDEX) = LT- 
DELtMINATOR 
END- PERFORM. 

MOVE (WS- FILE-STREAM FROM START-INDEX 
TO WS-INDEX) TO WS-SEX. 

PERFORM 1000-PARSE-CUSTOMER-STREAM 
THRU lOOO-PARSE-CUSTOMER-STREAM-END. 
ELSE IF (WS-FILE-STREAM FROM WS-INDEX TO (WS-INDEX + 
5)) - "SEX " 
THEN 

*** FIND THE DELIMINATOR AFTER THE SEX STRING AND 
MOVE *** 
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THE SEX VALUE INTO THE SEX VARIABLE 
MOVE WS-INDEX TO START-INDEX. 
PERFORM 

VARYING WS-INDEX 

FROM START- INDEX 

BY 1 

UNTIL (WS-FILE-STREAM-IN AT WS-INDEX) = LT- 
DELIMINATOR 
END- PERFORM 

MOVE (WS-FOJE-STREAM FROM START-INDEX 
TO WS-INDEX)TO WS-SEX 

PERFORM 1000-PARSE-CUSTOMER-STREAM 
THRU lOOO-PARSE-CUSTOMER-STREAM-END. 
ELSE IF (WS- FILE-STREAM FROM WS-INDEX TO (WS-INDEX 
+5)) - "AGE " 
THEN 

**" FIND THE DEUMINATOR AFTER THE AGE STRING AND *" 
*** MOVE THE AGE VALUE INTO THE AGE VARIABLE "** 
MOVE INDEX TO START-INDEX. 
PERFORM 

VARYING WS-INDEX 

FROM START-INDEX 

BY 1 

UNTIL (WS-FILE-STREAM-IN AT WS-INDEX) = LT- 
DELIMINATOR 
END-PERFORM 

MOVE (WS-FILE- STREAM FROM START-INDEX 
TO WS-INDEX)TO WS-AGE 

PERFORM 1000-PARSE-CUSTOMER-STREAM 
THRU lOOO-PARSE-CUTOMER-STREAM-END. 
ELSE 

PERFORM 2000-SAVE-CUSTOMER THRU 
2000-SAVE-CUSTOMER-END. 
END- IF. 

1000- PARSE-CUSTOMER-STREAM-EXIT. 
2000-SAVE-CUSTOMER. 

*** CALL A SQL MODULE TO SAVE THIS INFORMATION IN 
THE 

*** RELATIONAL DATABASE 

CALL "SAVE-CUSTOMER- IN- DATABASE" USING WS- 
CUSTOMER 

2000-SAVE-CUSTOMER-END. 



Conversely, a stream could be created by a non-object 
system or another object system, populated with cus- 
tomer information, and sent to one's object-based sys- 
tem. Once in the object-based system, the Customer- 
Object could use a "streamOff: aSteam" method, 
instanciate a CustomerObject, and populate it with the 
appropriate attribute values. 
Collaborations 

Stream -based Communication. This is the parent pattern 
to the Self-Describing Stream pattern. In this pattern, infor- 
mation is transmitted using a simple stream and a shared, 
generic format. The Self-Describing Stream is a more spe- 
cific implementation of Stream-Based Communication. 

Bridge (from the Gamma book Design Patterns) describes 
a way to de -couple an abstraction from its implementation 
so that the two can vary independently. The Bridge pattern 
is often used to define collaborations between a business 
object and a format object while decoupling the business 
object from its specific stream format. 

Abstract Factory (from the Gamma book Design Patterns) 
is a pattern for creating families of related classes. This 
could be used with the Bridge pattern to retrieve the format 
dynamically based on non-static information. 
Alternatives 

Fixed Format Stream — This pattern is a specific variation 
of Stream -Based communication where the messaging for- 
mat is defined and stored on both the sending and receiving 
systems. 



Downloadable Format Stream — This pattern is a specific 
implementation of Stream-Based communication where the 
messaging format is stored at a central location and is 
downloaded by the communicating parties when needed. 
Stream-based Communication 

FIG. Ill illustrates a flowchart for a method 11100 for 
providing a stream-based communication system. A shared 
format is defined on interface code in operation 11102 for a 
sending system and a receiving system. A message to be sent 
from the sending system to the receiving system is translated 
based on the shared format in opration 11104. The message 
is sent from the sending system and received by the receiv- 
ing system in operations 11106 and 11108. The message 
received by the receiving system is translated based on the 
shared format in operation 11110. 

As an option, information in the translated message 
received by the receiving system may be stored in a rela- 
tional database. As another option, , the shared format may 
be based on an order of attributes in the message. 

In one version, one of the systems may be an object-based 
system and one of the systems may be a non-object-based 
system. In another version, both of the systems may be 
object-based systems. In a third version, both of the systems 
may be non-object-based systems. 

In order to successfully transmit a formatted message, 
both the sending and receiving systems must understand the 
format and structure of the transmitted information. Some 
communications mediums, however, do not inherently trans- 
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mil the formatting information with the data. How cao 
information be easily communicated between systems when 
the communication mechanism does not inherently convey 
data structure or other meta-data information? 

For two systems to successfully communicate, they must 
understand the structure of the data they are passing. The 
sending system needs to convert standard programming 
constructs (objects, structure, strings etc.) into bytes of data 
that can be transmitted along a network. The receiving 
system needs to receive the bytes of data on a wire and 
reconstitute it back into objects, structure, strings etc. 

Many communication mechanisms inherently provide 
this functionality to a software developer. CORBA and 
DCOM are two examples of this type of middleware. Using 
CORBA, one system can send a structure of information to 
another system. CORBA will convert the structure into a 
network appropriate format, transmit it across the network 
and reformat it on the receiving end. 

Other types of middleware, however, do not provide this 
full range of functionality. Lower level communication 
protocols like TCP and UDP as well as higher-level proto- 
cols like HTTP and telnet do not provide support for sending 
data structures. 

Additionally, popular message queuing software (IBM'S 
MQSeries and BEA MessageQ) and many custom commu- 
nications mechanisms are lacking support for transmitting 
structured data across the network. 

These communication protocols do not inherently convey 
meta-data information. 'Meta'-data is information about the 
data. Meta-data could describe the data structure (senders 
address in bytes 1-10, receivers address in bytes 11-20, data 
in 21-100, etc.), data types, etc. 

When the highest- level common communication protocol 
between two systems cannot convey this meta-data 
information, an alternative communication mechanism is 
needed. 

FIG. 112 illustrates how systems 11200, 11202 of the 
present invention communicate over a communication 
mechanism 11204 that cannot inherently convey meta-data 
information. 

How can they exchange structured data? 

In object-based systems, issues with conveying meta-data 
are even more prevalent. Object-based systems often need to 
transfer object information across non-object communica- 
tion mechanisms (e.g. DCE, . . . ) or to non-object systems. 
Because neither non-object communication mechanisms nor 
the non-object systems understand the notion of objects, 
how can the structure of the objects be meaningfully con- 
veyed? 

FIG. 113 is an illustration of an object-based system 
11300 communicating with a non-object system 11302 using 
a communication mechanism 11304 that cannot convey 
meta-data information. 

How can they exchange structured data? 

Therefore, use Stream-based Communication to transmit 
information between systems. Stream the data between the 
two systems and use a generic format to relay the informa- 
tion and its associated meta-data between the systems. 

A stream is simply a buffer that data is "written to" and 
"read from" in discrete quantities. The size of the buffer is 
predetermined and can be very small (i.e. one byte in length) 
or very large (i.e. a page). The buffer can't hold objects or 
structures, but just raw data. Buffers are quite dumb and 
don't understand anything about their raw data. Thus, it does 
not have meta data for the information in the buffer. 

The "shared format" provides the meta-data information 
needed to interpret the raw data in the buffer. This shared 
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format is like a secret decoder ring for systems sending and 
receiving messages. The sending system uses the decoder 
ring to convert objects, structures, etc. into raw data on a 
stream. The receiving system uses another decoder ring to 

5 reconstitute the raw data back into objects or structures. If 
objects aren't supported, the raw data is converted into a 
comparable format for use by the receiving system. 

FIG. 114 depicts an example of Stream Based Commu- 
nication with two disparate systems 11400, 11402 commu- 

lQ nicating via stream-based communication 11404. 

In FIG. 114, the object-based system 11400uses a shared 
format (decoder ring) to convert an object into raw data. The 
raw data is then copied onto the stream. The stream then 
delivers the data to the Non-Object system 11402. The 
Non-Object system 11402 reads the raw data and reconsti- 

15 tutes the data using its shared format. 

In this example, the sending system is sending objects 
while the receiving system doesn't understand objects. Thus, 
the receiving system can only convert the raw data into a 
data equivalent of the object sent. 

20 Benefits 

Maintainability. When using this pattern, a shared, generic 
format is used to interpret the data. As a result, the two 
systems are de-coupled and less dependent upon each 
other. As long as the format remains unchanged, 
25 changes to the internal implementation of either system 
will not affect the other system. Maintenance of 
decoupled systems is easier. 
Batch Compatible. Strings of data can be concatenated 
and transmitted as a group. This enables batch mes- 
30 saging (e.g. Request Batcher) and processing. 

Enables Lightweight Persistence. Stream-based commu- 
nication can be used to interface with a lightweight 
persistence mechanism. Objects, structures, etc. can be 
can be converted to raw data and streamed to a flat file 
35 for saving. At a future time, the file can be opened, the 
raw data can be streamed out of the file and reconsti- 
tuted into full blown objects or structures. 
The implementation of Stream Based Communication is 
very straightforward. Simply define interface code on the 
40 sending system that creates a stream and parses the data onto 
this stream using a format shared by the both the sending and 
receiving systems. On the receiving system, define interface 
code that reads the stream and, using the same shared 
format, parses the data off of the stream and into a data 
45 structure compatible with the receiving system. 

The specific implementation of the formats can be, and 
most likely will be, different from system to system but the 
actual format must be shared and should be generic between 
systems. Shared so that the information is accurately relayed 
so and generic to keep the systems as de -coupled as possible by 
not exposing any implementation details of either system in 
the format. Further, this shared format can be implemented 
in a variety of places depending upon the specific require- 
ments of the interface. 
55 For object-based systems, make each object responsible 
for implementing streaming behaviors that use this shared 
format. Each object should use the format as a map to parse 
the attribute values onto a stream (streamOn). Conversely, 
each object class should use the format as a map to parse its 
60 attribute values off of a stream and put them into a newly 
instantiated instance of the object (streamOff). 

In the example below, an object within an object-based 
system uses stream-based communication to stream its 
attribute values onto a stream. Then a communication 
65 mechanism transports the stream to a non-object system, and 
a non-object system reads the information off of the stream 
and inserts it into its relational database. 
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FIG. 115 is an illustration of a Customer object 11500 in 
an object-based system 11502 streaming itself into a stream 
11504, the stream 11504 being sent to a non-object system 
11506, this stream 11504 being read and the information is 
inserted into a relational database 11508. 
1. The CustomerObject with attributes name, sex, and age 
has a method "streamOn: aStream," It is invoked with an 
empty stream as the argument 'aStream*. The Customer- 
Object "streamOn:" method goes through each of the 
object's attributes and parses each values as a string onto 
the stream. 

The fixed format contract here is embodied in the order 
that this method parses the attributes onto the stream. A 
pseudo-code example in Java is the following: Note — 
Assume that "asString( )" converts the receiver to a 
string and that "padWithSpaces( )"pads the string with 
spaces and makes the string the length specified. 



/** Stream my attribute values on aStream "*/ 
public void streamOn (OutputStream aStream) 

{ 

aStrea m. write (t his. getNameO-asStringO- pad WithSpaces( 10)); 

aStrea m .write (t his. getSex O-asStringO- pad WithSpaces (7)); 2 5 

aStream.write(this.getAge0.asString0.padWithSpaces(3)); 

} 



DATA DIVISION. 
FD FILE-STREAM-IN 

RECORD CONTAINS 20 CHARACTERS 

WORKING-STORAGE SECTION. 

*** THIS COPYBOOK CONTAINS THE SHARED FORMAT OF 
THE 

*** CUSTOMER IN THE DATA STRUCTURE AND DATA TYPES 

01 WS- SHARED- FORMAT-CUSTOMER 

03 WS- SHARED- FORMAT-NAME PIC X(10). 

03 WS-SHARED-FORMAT-SEX PIC X(7). 

03 WS- SHARED- FORMAT- AGE PIC 999, 

THIS COPYBOOK IS THIS SYSTEMS VIEW OF A CUSTOMER 
Ol WS-CUSTOMER 

03 WS-NAME PIC X(10). 

03 WS-AGE PIC 999. 

03 WS-SEX PIC X(10). 

PROCEDURE DIVISION. 

••• OPEN THE FILE STREAM AND PUT THE CONTENTS IN THE 

WS-SHAR ED- FORMAT-CUSTOMER COPYBOOK. 
OPEN FILE- STREAM- IN 

READ FILE-STREAM- IN INTO WS- SHARED- FORMAT- 
CUSTOMER 

AT- END CLOSE FILE-STREAM- IN 
END- READ. 

*•• MOVE THE VALUES INTO FROM THE SHARED FORMAT 
INTO 
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. The stream is then put into a message communication 
mechanism like MQSeries or Message Q and sent to the 
non-object system. 

. Once at the non-object system, interface code reads 
through the stream, parses the values off of the stream, 
converts them to the appropriate types if required, and 
puts them in a copybook with the appropriate structure. In 
this example, the fixed format contract is embodied in the 
structure and type of the WS -SHARED- FORMAT- 
CUSTOMER working-storage copybook. Refer to the 
pseudo-COBOL example below. 
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THE WS-CUSTOMER VARIABLES. 
MOVE WS-SHARED-FORMAT-SEX TO WS-SEX. 
MOVE WS-SHARED- FORMAT-AGE TO WS-AGE. 
MOVE WS-SHARED- FORMAT-NAME TO WS-NAME. 

CALL A SQL MODULE TO SAVE THIS INFORMATION IN 
THE 

RELATIONAL DATABASE 
CALL "SAVE-CUSTOMER-IN-DATABASE" USING WS- 
CUSTOMER. 



STOP-RUN. 



Conversely, a stream could be created by a non-object 
system (or another object-based system for that matter) 
and sent to one's object-based system. In this case, 
CustomerObject could use a "streamOff:aStream" 
method and instanciate A new instance of a a Customer- 
Object and populate it with the appropriate attribute 
values. 

Again, there are several variations of this pattern depend- 
ing upon what the specific requirements are. Some of these 
variations are further explained in the children patterns. 
Refer to Fixed Format Stream, Downloadable Format 
Stream, and Self -describing Format Stream. 
Collaborations 

Fixed Format Stream — This child pattern is a specific 
variation of Stream-Based communication where the mes- 
saging format is defined and stored on both the sending and 
receiving systems. 

Downloadable Format Stream — This child pattern is a 
specific variation of Stream-Based communication where 
the messaging format is stored at a central location and is 
downloaded by the communicating parties when needed. 

Self-Describing Stream, This child pattern is a specific 
variation of Stream-Based communication where the mes- 
saging format is parameterised and stored on the stream. A 
message language is used to read and write the format of the 
message from the stream. 

Structure Based Communication — This pattern uses a 
Fixed Format Stream to transmit data structure between 
systems. It is often used to obtain data from a Server for 
display in a Client UI. 

Bridge (from the Gamma book Design Patterns) describes 
a way to de -couple an abstraction from its implementation 
so that the two can vary independently. The Bridge pattern 
is often used to define collaborations between a business 
object and a format object while decoupling the business 
object from its specific stream format. 

Abstract Factory (from the Gamma book Design Patterns) 
is a pattern for creating families of related classes. This 
could be used with the Bridge pattern to retrieve the format 
dynamically based on non-static information. 
Structure-Based Communication 

FIG. 116 illustrates a flowchart for a method 11600 for 
eflSciendy retrieving data. A total amount of data required for 
an application executed by a client is determined in opera- 
tion 11602. In a single call, the total amount of data from a 
server is requested over a network in operation 11604. All of 
the data is bundled in operation 11606 into a data structure 
by the server in response to the single call. In operations 
11608 and 11610, the bundled data structure is sent to the 
client over the network and the data of the data structure is 
cached on the client. The cached data of the data structure is 
used as needed during execution of the application on the 
client in operation 11612. 

The data structure may be bundled on the server by a 
business object. In addition, the business object may be 
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instantiated by an action of the client. Also, the network may 
be at least one of a local area network and a wide area 
network. As a further option, the request may be adminis- 
tered by a proxy component. Further, the data structure may 
contain no logic. 

In a client server application, the client communicates 
with a server over a network. Depending upon the speed of 
the network and the number calls across the network, an 
application can experience performance problems. How can 
a client update a server while minimizing the network traffic 
and maintaining an acceptable level of system performance? 

Acceptable system performance is an important attribute 
of every application. When creating a client-server 
application, the performance of the network must be con- 
sidered during the design and development of an applica- 
tion. The speed at which data can be transmitted across the 
Local Area Network or Wide Area Network, can make or 
break a client-server application. 

In a typical three-tiered client-server application, the 
business objects are maintained away from the users (Client) 
on separate Server machines. Whenever a user needs the 
expertise of a business object, the user must send a request 
across the network to the Server machine. 

FIG. 117 illustrates the manner in which a client 11700 
requests information from server objects 11702 via a net- 
work 11704. 

Depending upon the size of the message and the speed of 
the network, this could take a long time. This is a reality of 
three-tiered client-server applications. 

When a client-server application is introduced to the 
world of distributed objects, the network can become an 
even larger bottleneck. In a pure distributed object approach, 
the client is passed an object reference to a business object 
on a server machine. The client then accesses the specific 
business object over the network as if it resided on its local 
machine. Using this "pure" distributed object approach, the 
application's calling pattern begins to look like the sche- 
matic of FIG. 118. 

FIG. 118 illustrates the method of the present invention in 
which a client 11800 requests attributes from a server object 
11802 via a network 11804. 

This is an excellent programming model that frees the 
developer to access local and remote objects in the same 
fashion. Unfortunately, it makes it easier for the application 
developer to forget about the physical realities of the net- 
work. A network call is always slower than a call within a 
single machine. Ignoring this reality may result in an unac- 
ceptably slow application. 

On a very fast LAN where the number of network calls is 
small, this calling pattern may be acceptable. On a slower 
LAN, any WAN or when the number of network calls is 
large, this pattern will yield unacceptable network perfor- 
mance. Something must be done to maintain an acceptable 
level of system response for the users. 

FIG. 119 ilustrates the transmitting of all data in a Data 
Structure 11900 from a client 11902 to a server 11904 and 
visa-versa. As shown, to maximize the performance on the 
client, it is best to bundle all the necessary data into a single 
data structure that can be transmitted as a structure across the 
network. 

The Client would first determine the sum total of every- 
thing it will need from the business object on the Server 
machine. The Client makes a request for all of this data from 
the business object. The business object bundles all the data 
into a data structure and returns it to the client. The Client 
will cache this data (using the Caching Proxy pattern) on its 
local client machine and use it as needed. 
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Benefits 

Better System Performance — This pattern will improve 
the performance of an application by reducing the 
network traffic between the client and the server. The 
s client makes one network request to retrieve all of the 
data from the server. Regardless of the number of 
displayable attributes the application will only make 
one network send. 
Without this pattern, the client could make a network send 
30 for every attribute retrieval. If the user wants to retrieve 
a customer's name, address and phone number, that 
could result in three network requests (one for each 
attribute). Without this pattern, the network traffic can 
become prohibitive and the performance would suffer. 
is Structure Based Communication assumes a client needs 
information from an object that exists on a server. Thus, this 
pattern assumes the existence of an "interesting" object on 
the server machine. 

Even though the "finding" and "instantiating" of a server 
object isn't part of this pattern, it does establish context and 
20 sets the stage for the pattern. As a result, a message trace 
diagram for finding and instantiating a particular object 
instance is shown below. This will set the stage for the 
implementation of the Structure Based Communication pat- 
tern. 

25 FIG. 120 illustrates the method in which a client 12000 
finds and instantiates a Customer Object from a customer 
component 12002. The various steps shown in FIG. 120 will 
now be set forth. 
Collaborations 

30 1. The client instantiates a Proxy (Customer Component 

Proxy) to the Customer Component. The Client then asks 

the Proxy for Customer Jimbo Jones, 
2. The Customer Component Proxy forwards the request 

across the network to the Customer Component. 
35 3. The Customer Component requests the information for 

Jimbo Jones from the database, 

4. The Database returns the data associated with customer 
Jimbo Jones. 

5. The Customer Server Component instantiates a customer 
40 object using the Jimbo Jones data from the database. 

6. The Customer Server Component returns a remote object 
reference to the "Jimbo Jones" object running on the 
Server. 

7. The Client creates a proxy to the "Jimbo Jones" object 
45 using the remote object reference. 

Now that a customer object (Jimbo Jones) exists on the 
server component, Structure Based Communication can be 
used to pass the needed data from the server to the client. 

FIG. 121 ilustrates a Structure Based Communication that 
50 builds upon the method of FIG. 120 and depicts the flow of 
control during Structure Based Communication. The various 
steps shown in FIG. 121 will now be set forth. 
Collaborations 

8. The Client asks the Customer Proxy for the data associ- 
55 ated with the Jimbo Jones object. 

9. The Customer Proxy forwards the request across the 
network to the Customer Component 

10. The Jimbo Jones object creates a data structure and 
populates it with its data. 

60 11. The Data Structure is passed across the network to the 
Customer Proxy on the Client. 

12. The Customer Proxy forwards the data structure con- 
taining Jimbo Jones' data to the Client component. 

Participants 

65 Client — The "client" for the transaction. This could be a 
User Interface that displays customer data for viewing 
by a Customer Service Representative. 
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Network — A LAN or WAN network that connects the 

Client with the Customer Component. 
Customer Component — A server component that encap- 
sulates the data for all of the customers in a system. 
Customer Component Proxy — A proxy to the Customer 
Component. Any request it receives, it forwards across 
the network to the Customer Component. 
Customer Proxy — A proxy to the Jimbo Jones Customer 
Object Any request it receives, it forwards across the 
network to the Jimbo Jones Customer Object. 
ACustomerStructure — A data structure. It contains the 

data (but no methods) from the Jimbo Jones object. 
Database — Any relational database. 
Jimbo Jones Object — An object that represents the Jimbo 
Jones customer. This object contains Jimbo Jones* data 
and methods associated customer methods. 
Sample Java Code 

The following java example accompanies the previous 
message trace diagrams. The java code follows the same 
scenario as the message trace diagrams, but it has been 
simplified in some areas. 

The following snippet of code defines the data structure 
used to pass customer information. 



public CustomcrStructure( 
String firstName, 
String lastName, 
short strcctNumber, 
String street, 
String city, 
String state, 
String zipCode) 



// Client side code here. 

Main() 

{ 

// Create a Proxy to the Customer Component. 
CustomerComponentProxy aCustomerComponentProxy = 

new CustomerCoinponentProxyO; 
// Get a Proxy to the Jimbo Jones Customer 
// object. 

CustomcrProxy aCustomcrProxy = 

aCustome rCompone ntProxy.ge tCusto me r(" Jimbo Jones"); 
// Get Customer data from the Customer Server 
// Component(Call across the network) 
Customers tructure aCustomerStructure - 

aCustome rProxy.getCusto merAsS tructureO; 
// Use the Customer data received in the 
// structure. For Example, display the data 
// structure data (aCustomerStructure) in a UL 



The following code is a sample Customer Server Com- 
ponent. The Customer Server Component is used to retrieve 
the data associated with customer Jimbo Jones from the 
database. It also instantiates a customer object using the data 
retrieved from the database. 
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// Put the data associated with a Customer Object 

// into a data Structure. This data structure 

// will be sent across the network to a client. 

public Customer gctCustomer(String aCustomerName) 

{ 

// Find the Customer in the database 



10 



15 



20 



} 



// Instantiate the Customer Object 
Customer aCustomer - new Customer (.. 



// Return a "remote object reference" 
// Jimbo Jones Customer object, 
return (aCustomer); 



Finally, this is the code for the Jimbo Jones Customer 
object. 



25 
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35 



// Customer object code here 
public class Customer 
{ 

// Put the data associated with a Customer Object 
// into a data Structure. This data structure 
// will be sent across the network to a client, 
public CustomerStructure getCusto me rAsS tructureO 
{ 

CustomerStructure aCustomerStructure = new 
Cus tome rS tructure 0; 

aCustome rS tructure. firs tName - this.getFirstNameO; 
aCustomerStructure. lastName ■= this, get LastName 0; 
aCustomerStructure.streetNumber - this.getStreetNumberO; 
aCustome rStructure.street = this.getStreetQ; 
aCustome rStructure.city = this.getCityO; 
aCustomerStructure.state - this.getStateO; 
aCus tome rS tructure .zipCode - this.getZipCodeQ; 
return aCustomerStructure; 

} 

// Getters and Setters for all attributes 
// (code not shown here) 



50 



55 



Note: The "Main 1 ' code example above obtains a Proxy to 
customer "Jimbo Jones" and then a Structure of data through 
the proxy. The code was written for ease of understanding, 
but causes two calls across the network. In reality, it is 
preferred to perform both functions using one network call. 
Limiting the number of network calls will improve system 
performance. The recommended code might look something 
like this: 



60 



// Customer Component Code here 
public class CustomerComponent 



65 



// Create a Proxy to the Customer Component 
// (same as above) 

CustomerComponentProxy aCustomerComponentProxy ■ 

Cus tome rComponentProxyO; 

// Get a Proxy to the Jimbo Jones Customer 

// object 

// AND 

// customer data at the same time. 
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CustomerProxy aCustomerProxy; 
CustomcrStructurc aCustomcrStructurc = 

aCustomcrComponcntProxy.getCustomcrData("Junbo Jones", 
aCustomcrProxy); 



Collaborations 

Proxy — This pattern is documented in the book "Design 
Patterns" by Gamma, Helm, Johnson and Vlissides. The 
proxy pattern is often used to communicate with server 
components in a distributed environment. The Proxy pattern 
is often used to retrieve data structures from a server 
component. 

Cached Proxy — This pattern is documented in "The 
Proxy Design Pattern Revisited" section of the Pattern 
Languages of Programming Design 2 book. A Cached Proxy 
caches data locally on the client. Structure Based Commu- 
nication uses and builds upon this pattern. 

Globally Addressable Interface — This pattern often works 
in conjunction with Structure Based Communication. 
Oftentimes, a Globally Addressable Interface is used to 
obtain Structures of data for display on a Client. 

Locally Addressable Interface — This pattern can also be 
used in conjunction with Structure Based Communication. 
After establishing a relationship with an LAI, a client may 
obtain data from the Server object using Structure Based 
Communication. 
Alternatives 

Distributed Objects — The "pure" distributed object 
approach is an alternative to Structure Based Communica- 
tion. Using this pattern, individual objects are queried for 
each piece of information needed by a client. 

Presentation Services (1000) 

Presentation Services enable an application to manage the 
human-computer interface. This includes capturing user 
actions and generating resulting events, presenting data to 
the user, and assisting in the management of the dialog flow 
of processing. The Presentation Services forward on the user 
requests to business logic on some server. Typically, Pre- 
sentation Services are only required by client workstations. 

In addition to Presentation Services on the client, some 
business logic will usually reside on the client as well to aid 
the Presentation Services. Even on thin clients some sort of 
validation logic is usually included with the Presentation 
Services. A quick review of the Gartner Group's five styles 
of client/server computing help to illustrate this. 

FIG. 122 shows the Gartner Group's Five Styles of 
Client/Server Computing 12200. 

The way that Presentation Services interact with client- 
side business logic is very important to the overall scalabil- 
ity and maintainability of the application. An application's 
business logic is expected to be highly reusable, even on the 
client. If business logic is coupled with the Presentation 
Services too tightly, it will be very difficult to separate and 
reuse the business logic if the Presentation Services ever 
need to be altered (not an uncommon occurrence). 

The patterns in this section help to guide application 
architects on strong, proven techniques to safely integrate 
client-side business logic with an application's Presentation 
Services. The Activity pattern lays the groundwork for 
separating the Presentation Services and business logic on 
the client by assigning non-presentation logic to a type of 
object called an Activity. The View Configurer pattern helps 
to assign new views with their appropriate Activity. Finally, 
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the User Interface Validator pattern describes how to imple- 
ment customizable, extendable validation logic on a user 
interface. 
Activity * 

5 FIG. 123 illustrates a flowchart for a method 12300 for 
providing an activity module. A server and a presentation 
interface of a client are interfaced to permit the receipt of 
requests for service from the presentation interface of the 
client in operations 12302 and 12304. A portion of the 

10 requests are handled on the client in operation 12306. In 
operations 12308 and 12310, another portion of the requests 
are forwarded to the server for further handling purposes and 
changes are effected in the presentation interface. 

A plurality of presentation interfaces may be interfaced. 

15 Optionally, a model may be interfaced for management 
purposes. With such an option, the model may further 
include a proxy. As another option, errors and exceptions 
may also be handled. As a third option, events intended to be 
received may be triggered by the presentation interface. 

20 Many client/server applications maintain some amount of 
business logic on the client. How can an application repre- 
sent and reuse "client-side" business logic across multiple, 
volatile user interfaces? 

Imagine a typical client/server system design. In almost 

25 all cases, a typical system executes data access logic on the 
server and presentation logic on the client, business logic is 
split across both the client and server. The majority of this 
business logic is maintained on the server. This logic 
is-represented by various components and business objects 

30 that can communicate with each other to complete a variety 
of system use cases. 

The client, on the other hand, is mostly responsible for 
supporting user interactions with the system. To be 
successful, the client must also execute some degree of 

35 business logic. While this can vary from implementation to 
implementation, some categories of logic are invariably 
located on the client. This includes simple data validations, 
representing data structures and relationships, error and 
exception handling, and communications with the server. 

40 To complete a single use case, the client may need to 
interact with a number of server components. From the 
user's perspective, one unit of work is being performed but 
it may involve multiple, discrete interfaces and multiple 
server invocations. Some business logic is required to man- 

45 age the complex flow to complete this unit of work. For 
example, suppose a use case for a network inventory man- 
agement system is "Add Network Card". This may require 
the user to input information in three or four screens and 
client communication with more than one server component. 

50 Managing this flow is not the responsibility of the presen- 
tation logic but still needs to be executed on the client. 

The system may also require a number of interfaces to 
complete the same use case. Depending on the user category 
executing the use case, the interface may be a PC, a 

55 handheld device, or a telephone. Even on the same type of 
device, the interface may differ depending on the user 
category. Some users may want to access the application via 
a standard Windows interface while others may want to 
access it via a "web-centric" interface (internet browser). In 

60 all of these cases, the unit of work to be completed by the 
user is not changed and should be reused. 

FIG. 124 illustrates multiple interfaces to an application 
12400 including a handheld device 12402, a desktop PC 
12404, and a telecommunications device 12406. 

65 Often these user interfaces will be changed over time to 
fit user's changing needs. While the tasks completed by the 
user may not change, the interface to complete those tasks 
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will need to, Windows users will want to move to the Web. Collaborations 

Web users will want to move to handheld devices. The Facade — The Activity acts as a Facade to all of the server 

presentation code should be able to be changed without components by coordinating a user interfaces interaction 

causing a rewrite of the business logic on the client. wlh tnem * 

Therefore, bundle business logic executed on the client 5 Separation of Concern— Dividing defined responsibilities 

separate from the presentation logic. This new type of class "?!° **"«f classes (presentation logic into UI classes and 

is an Activity client-side business logic into activity classes). 

An Activity is responsible for: Observer-An activity's interfaces are observers of that 

J r activity. 

managing client logical units of work Us** Interface Validator 

maintaining client representation of a business model FIG. 128 illustrates a flowchart for a method 12800 for 

validation across multiple interfaces (complex business structuring validation rules to be applied to a user interface 

logic) f° r max i mum maintainability and extensibility. In opera- 

tions 12802 and 12804, a plurality of user interface widgets 

error and exception handling are provided along ^h a plurality of validation rules which 

communication with server and other services 35 govern use of the user interface widgets. A user is allowed 

creating other Activities in operation 12806 to select the validation rules to associate 

triggering events intended to be "caught" and acted on by wi \* ihQ u ™ inte ^ ce widgpls of a first user interface. The 

the presentation loeic validation rules of the user interface widgets of the first user 

» A j u . «u * i ■ 4 r j interface are automatically associated across a plurality of 

An Activity resides between the actual user interface and „ ..~ 4 . / - . . iX ono J 

iL . . j i j . . ■ . L 20 separate different user interfaces in operation 12808. 

the business model and server components as shown in the V, ... .. , _ . . \ t . . a . 

■j-i . »■* . . , . ,. . , r The vahdation rules may be created at the time the first 

Entity Relationship diagram below: . , c . » f t , . . , t . 

t-i^ mi . * i u- j * user interface is created. As another option, the vahdation 

FIG. 125 illustrates an activity entity relationship dia- . i_ • i * ^ u j*<r . i r i_ . 

J J r rules may be implemented by a different class for each type 

^i^-i • . c • . * c . *i_ of validation. As a further option, an indicator may be 

While any user interface maintains a reference to the ,. , , c t , <• , . • • i * j 

a .• ninn - t * j ■ . _r ivai r *t_ 25 displayed upon one of the validation rules being violated. 

Activity 12500 it provides an interface 12502 for, the A : „ r , ... , . ° . , 

. ... * t_ \ • r • Additionally, each validation rule class may extend an 

Activity is unaware of what (if any) interfaces exist on it. , 4 t : . . . , , . , a t . . c 

™. . ' .. „ r , v J/ . ca M.-I- abstract validation rule class that defines what types of 

This decoupling allows for a large amount of flexibility with . , , A1 4 e ,. r , 

. . r * * ,. • c widgets are supported. Also, a request for the validation 

the interfaces to an application. Multiple types of interfaces , „ , • j r c .l 

. . r \ c * i- •/ * • j * rules may optionally be received from one of the user 

can exist on a single type of Activity. Code is reused and 3Q j nter f aces 

none is lost if presentation logic is replaced with something TT ' . , . . , . 

different CaD structure vau " auon ru^s to be applied to a 

...... ' . . - . j. .| user interface for maximum maintainability and extensibil- 

While a user mterface can communicate directly with its . J 

associated activity, an activity should never directly com- , t . , , . . . ,. t/ 

J c . A . / - ™ . ., , Imagine a typical Windows or web-based chent/server 

municate with any of its interfaces. This would set up a , r »• ¥ . u « * a » * e 

, j 4 i * u j iL a -L i-. r 35 application. In most cases where a windows type of user 

dependent relationship that would reduce the flexibility of • ; c • j j i- ** * u • 

the activit interface is provided, an application supports some business 

f 4 j . .. _r rules by validating data entered by the user. A common 

Instead, an activity can communicate to its interfaces i r * u i ■ *u r * r j * ■ 

, , l t . j . i example of this is checking the format of data in an entry 

through an event mechanism. Interfaces are set up as depen- c u ,l , • j n u ■ * i r* * 

* . Jt L . .. j . \ 11 r 4 L field or ensuring that a required field is not left empty, 

dents of the activity and the activity sends events to all of the r™,. , -.r Ti*- 

- *r- i- r j-jl lji.u40 The business rules supported by user interface validation 

interfaces on it. Each interface can decide how to handle the „ i_ . i- j tl c tU » 

is usually somewhat limited. The scope of these rules is 

event 

t-t^ ii . i j . i . j • generally constrained to checking if a field is empty, check - 

FIG, 126 illustrates a roles and responsibilities diagram. r . / . f fl u / j . • *\ 

r ^ mg the format of a field (date, time, numeric, currency, etc.), 

and checking if a field has alpha-characters, numeric- 
Maintainability. By separating the presentation and non- 45 characters, or both. In addition, due to fact that many 
presentation logic, the client is easier to understand and widgets provide constraints through their own form (list 
maintain. boxes, radio buttons), the types of widgets that require this 
Reuse. The presentation layer may be replaced or reused type of validation checking is also somewhat limited (text 

without affecting the non-presentation logic. fields, editable combo boxes, etc.). 

FIG, 127 illustrates a typical implementation between a 50 FIG. 129 illustrates widgets with their validation require- 

user interface and its activity. ments 12900. 

The diagram shows the various "layers" of interaction Because this type of validation will most likely be 

where the lightest shaded boxes are the presentation, the required across all of an application's user interfaces and the 

next darkest is the activity, and the darkest is the component fact that the types of validation rules and widgets needed to 

(proxies 12700). 55 validate are limited, this behavior is a strong candidate for 

A user request is captured and processed by the presen- a framework, 

tation object (NetworklnventoryUserlnterface 12702). In The framework would provide a common approach to 

this case, the processing involves simple validation (format validating user data across all of an application's user 

and "is null" checking), interfaces. Rules would be applied consistently throughout 

The presentation object then copies its data into a struc- 60 the application. While some common validation rules would 

ture representing some business entity (aNetworkltem be provided, the framework needs to allow their behavior to 

12704) and passes it to the activity 12706. The presentation be modified (overridden) and make it easy for new rules to 

object then triggers the activity to start its processing of the be added. 

new network item. Finally, both immediate and batch validation should be 

The activity then performs possibly more complex vali- 65 provided by the framework, 

dation and communicates with the server components to Therefore, for each user interface in an application, 

complete the use case. encapsulate their validation logic in a User Interface Vali- 
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dator. FIG. 130 illustrates a user interface validator associa- 
tion diagram. A User Interface Validator 13000 associates 
various validation rules with the user interface widget they 
are to be applied to. 

The associations are created at the time the user interface 
is created. The validations are triggered when deemed 
necessary by the user interface. Any validations that fail are 
displayed to the user including the type of validation that 
failed and the widget that it failed on. 
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this, add VaIidation(userNameField, new 

NotEmpty ValidationRule( )); 
this. add Validation(passwordField, new 

NotEmpty ValidationRule( )); 
this. add Validation(passwordField, new 

NotNumericValidationRule( )); 
this, add Validation(commentsArea, new 

MaxLengthValidationRule(255)); 
The add Validation method on the user interface is shown 
below. 



public void addVa!idation(ValidateWidget aWidget, ValidationRule aRulc) 

{ 

UlValidator myValidator = this. get \alidator( ); 
MyValidator.addAvlidation (aWidget, aRule); 

} 



The rules are implemented by a different class for each 
type of validation. Each of these validation rule classes must 
know how to check its rule for every type of widget that can 
be checked. As mentioned in the Context section of this 
pattern, this will most likely be limited to text entry type 
widgets. In addition, each validation rule class extends an 
abstract validation rule class that defines what types of 
widgets are supported. This is an implementation of the 
Visitor pattern. 

FIG. 131 illustrates a validation rule class diagram. 

Note that the check operations accept a Validate 13200 
type of class. Each widget that can be validated with this 
framework must implement a validateRule method. This 
simple method accepts some ValidationRule 13202 as a 
parameter and simply turns around and calls the check 
method on the rule passing itself in as a parameter. This 
interaction is shown in FIG. 132, which illustrates a rule 
validation interaction diagram. 

The concrete implementation of the check method will be 
invoked. This method knows how to extract the data from 
the particular widget provided and verify the rule. 

The User Interface Validator's job is to associate these 
rule instances with all of the widgets they pertain to. When 
the validate method is invoked on the Validator, all of the 
rules are sent to each of the appropriate widgets via the 
validateRule method. 

New rules can be added by creating new classes that 
extend off of the abstract Validation Rule class. No changes 
need to be made to the widgets. 
Benefits 

Consistency. All user interface validation rule checking is 

done in the same way using the same rule logic. 
Extensibility. New rules can be added without affecting 

any other part of the application. 
Automation. Application of validation rules can be auto- 
mated with a GUI based tool rather easily. 
The associations between a widget and the rule to apply 
to it should be set up when the user interface is created. A 
user interface can implement a method that accepts a rule 
and widget and passes it on to the User Interface Validator 
as shown in the code example below: 

ValidateTextField userNameField«new TextField("user 
name*'); 

ValidateTextField passwordField-new TextField 
("password"); 

ValidateTextArea commentsArea-new TextArea 
("comments); 



20 The add Validation method on the User Interface Validator 
is shown below. 

public void addValidation(ValidateWidget a Widget, Vali- 
dationRule aRule) 

25 



Hashtable rulesAndWidgets - this.getRulesAndWtdgets( ); 

if (rulesAndWidgets.containsKey(aRuIe)) 

{ 

aRulc » aRulc. clone( ); 

} 

rulesAndWidgets.put(aRule, aWidget); 



In the above code, three widgets are created and then 
associated with various validation rules. The user name and 

40 password fields are required and cannot be left blank, the 
password may not contain any numbers, and the comments 
text area may not be longer than 255 characters. 
Note that each of the widgets is created with a string that 

45 describes a name for the widget that the user would recog- 
nize. This name is used in the error list to help a user identify 
which widget failed validation. 

At some appropriate time, the user interface sends the 
validate message to the User Interface Validator. This 

50 method steps through each of the rules provided to it when 
the user interface initialized and passes them to their asso- 
ciated widget by the validateRule method. The code is 
shown below: 



public Vector validatc( ) 
{ 

Vector errors » new Vcctor( ); 

Hashtable rulesAndWidgets = this.getRulesAndWidgets( ); 
Enumeration rules ■ rulesAndWidgets. key s( ); 
while (rules.hasMorcElcmcnts( )) 
{ 

ValidationRule aRule - (ValidationRule)rules.nextElemeQt( ); 
ValidateWidget aWidget - (Validate Widget) 
Ru lesAnd Widgets .get(aRule) ; 
65 String anError - a Widget, validate Rule (aRule); 

if (anError !- null) 
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{ 

errors .add Element(anError); 

} 

} 

return errors; 

} 



Note that in the code example above, the validateRule 
message returns a String rather than a boolean. This string 
can be passed back to the user interface that invoked the 
validate and used to describe the errors that occurred to the 
user. 

Collaborations 

Visitor Each of the rules are implemented as a Visitor 
according to the GoF pattern of the same name. 
View Configurer 

FIG. 133 illustrates a flowchart for a method 13300 for 
assigning a view to an activity. Notification is received that 
a startup event of an activity has occurred in operation 
13302. A reference to a first instance of an object created by 
the startup event of the activity is also received in operation 
13304. In operation 13306, a view to launch is determined 
in response to the receipt of the notification and the refer- 
ence. The view is based on predetermined criteria. The view 
is associated with the activity and displayed in operations 
13308 and 13310. 

The predetermined criteria may include user preferences, 
an experience level of a user, security profiles, and/or 
workflow settings. Also, the activity may be allowed to run 
without a corresponding view. The activity may also operate 
on a machine separate from a machine of an end user. 

As an option, a request may be sent to be notified when 
a new instance of an object is created. As another option, a 
configuration file may be read for obtaining configuration 
information. 

How do I associate a new view with the appropriate 
business activity underneath, in a configurable manner? 

Consider a user interface that displays and collects data 
for an activity object underneath. 

The ICM/MVC patterns provide for a layered architec- 
ture. Each layer talks to a layer below it, and no lower layer 
talks to an upper layer. For example, the view messages 
downward to the activity and the business objects, and the 
activity messages to the business objects. Layers talk down. 
No layer messages back upward. 

Traditionally, activities launch their views directly. In the 
example illustrated below, the Search View tells the Search 
Activity to launch the Customer Maintenance Activity, 
which then opens up its own view. But this violates the ICM 
approach, because then the model is talking directly up to 
the view. 

FIG. 134 illustrates a manner in which the maintain 
customer activity operation 13400 of the present invention 
launches its view 13402. 

It might be more appropriate to let the view layer, rather 
than the activity Layer, make decisions about launching other 
views. The view layer already knows about usability 
preferences, positioning on the screen, etc. However, one 
wants the activities to control conversational flow for 
preconditions, postconditions, workflow, and any other addi- 
tional business logic, 

A view should not be able to launch a new, separate 
activity, because that involves business logic. Instead, one 
wants activities to launch other activities. When the activity 
layer controls conversational flow, one needs a mechanism 
to launch views on top of these activities, without violating 
ICM. 
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Therefore, a View Configurer 13500 will be created to 
manage the relationship between activities 13502,13504 and 
views. This would likely be a singleton. 

FIG. 135 illustrates the view configurer 13500 launching 
5 the maintain customer view operation. 

The View Configurer is a generic mechanism which 
allows launching of different views, based on certain crite- 
ria. It uses an observable relationship with activity factories 
to solve this problem. With the View Configurer, developers 
10 do not hard code the particular policies for the selection of 
a view. Moreover, this mechanism allows activities to run 
without a corresponding view. 

Communication from the activity to the View Configurer 
will be conducted through broadcasting (as described in the 
15 Observer pattern). In this manner, the activity doesn't know 
about the existence of the View Configurer, it listens to 
activity broadcasts such as when the controller starts up. 
This configurer can use the Observable Factory to get a 
handle to the activity instance. 
20 There are four main steps involved with the View Con- 
figurer observer/observable interface: 

Prior to the flow depicted above, the View Configurer has 
registered with the Activity Factory saying "Tell me when a 
new instance is created". This is an example of an "Observ- 
25 able Factory," which can be thought of as a Factory which 
implements the subject/observable role of the Observer 
pattern. The Factory needs to be a singleton, so the View 
Configurer has visibility to it. 
The Search View tells the Search Activity to launch the 
30 Maintain Customer Activity. 

The factory for the Maintain Customer Activity creates a 
new instance of the Maintain Customer Activity. 

Because the View Configurer has pre -registered an inter- 
est in the startup of activities, it will receive a broadcast 
35 message. In this step, the View Configurer should receive a 
minimum of two parameters: 

Notification of the startup event that has just occurred. 
A reference to the new instance of the object that was just 
created. 

40 The View Configurer then determines which view to 
launch. This can be based on a variety of criteria, such as 
user preferences, experience level, security profiles, or 
workflow settings. The configurer determines the correct 
view and attaches it to the activity underneath. 

45 Benefits 

Development. Depending on the distribution model in 
place, business processing can be executed and tested 
before the appropriate views have been implemented. 

50 Automated testing. The View Configurer is particularly 
useful when you want to use scripts and avoid bringing 
up windows with automated testing. This is especially 
true for performance testing, where you might want to 
run 100 transactions, which might involve instantiating 

ss 100 instances of the same activity. 

Running processes in batch mode. The View Configurer 
allows processes to run without a View, and makes it 
very simple to connect, disconnect, or reconnect related 
views. 

60 Distribution Transparency. In a distributed environment, 
the process might live on a different machine from the 
end user's machine. In that case, it cannot launch the 
view directly, within its own executable. (Unless using 
a remote windowing system like X- windows, etc.) So 

65 the View Configurer allows application architects to 
transparently move process logic around, depending on 
the distribution model. 
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Collaborations 

The Observer Pattern (Gang of Four Pattern) describes 
how to provide visibility to other entities via a one to many 
relationship. A singleton activity factory will create new 
activity instances, and broadcast the startup of the new 
activities to the View Configurer. 

An interface for the creation of activities is used in 
conjunction with the Observer Pattern. In this way, the 
startup of new activity instances can be broadcast to the 
View Configurer. This is described in the Factory Pattern 
(Gang of Four Pattern). 

Generally, there will only need to be one View Configurer 
per executable. The View Configurer would likely be a 
singleton, as described in the Singleton Pattern (Gang of 
Four Pattern). 

Environment Services (1016) 

Environment Services provide miscellaneous application 
and system level services that do not deal directly with 
managing the user-interface, communicating with other 
programs, or accessing data. These services are divided into: 

Operating System Services 

Runtime Services 

Version Management 

Licensing Services 

Error Handling/Logging Services 

Properties 

Task and Memory Management 
Security 

"Miscellaneous services" should not be interpreted as 
"less important services." In fact, they are vitally important. 
Developers are more productive when they are not required 
to be concerned over logging and auditing, error handling 
and context issues. Obtaining the freedom to largely ignore 
these issues requires close attention to providing facilities 
which are well thought out and meld into the application 
structure. 

Despite the pervasive demands of environmental 
considerations, many forms of documentation largely gloss 
over these issues. For example, many times when reading 
API documentation we find authors disclaim the fact that no 
error handling or "programming by contract" is shown 
within the code examples to improve readability. Yet, getting 
error handling right is key to stability in the execution 
environment. Programming by contract with the use of 
preconditions and post-conditions is perhaps the most 
aggressive style of programming known to date to assure 
correct programs. Assertion, Exception Hierarchies, Excep- 
tion Response Table and Polymorphic Exception Handler 
tackle these problems vigorously by helping to define clearly 
how to solve some of these key kernel application architec- 
ture considerations. The Exception patterns provide a blue- 
print illustrating how architectural issues can be abstracted 
into a service level component so that the impact to the 
application code is minimal. 

A demanding issue in distributed systems is gathering and 
using trusted information about the clients interacting with 
the systems. In earlier generations of systems the number of 
users was a fairly precise calculation — just count the number 
of workstations which could potentially connect to an appli- 
cation. Information about the users was also a fairly simple 
matter since they connected directly to the resources from 
which they were requesting services. Today, with clients 
offering web services within n-tiered architectures this is no 
longer easily predictable. In addition, requirements to sup- 
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port these less predictable numbers of users and to have a 
personal "one-to-one" relationship with them is key to many 
web strategies. The LoadBalancer and UserContext pattern 
offer some help in this area. The former addresses strategies 

5 for ensuring maximal leverage of the system resources and 
services and the latter helps in addressing the issue of 
maintaining state and context about the user. These facilities 
are mandatory when security, auditing and logging are 
considered essential properties of the environment. 

10 Assertion 

FIG. 136 illustrates a flowchart for a method 13600 for 
testing successfulness of an operation having pre-conditions 
and post-conditions that must be satisfied for the operation 
to be successful. A first assertion is raised in operation 13602 

15 asserting a pre-condition that must evaluate to true if the 
operation is successful. The operation is then executed in 
operation 13604. A second assertion is raised in operation 
13606 asserting a post-condition that must evaluate to true 
if the operation is successful. An error message is outputted 

20 upon failure of at least one of the assertions in operation 
13608. 

Optionally, an error handler may be provided for detecting 
a failure of the assertion of one of the conditions and 
shutting down a system running the operation upon the 

25 detection of the failure. As another option, an assertion may 
be raised at the beginning and end of every operation of a 
plurality of operations. Also, a check may be performed 
prior to raising the assertions for determining the propriety 
of raising the assertions. 

30 Each assertion may be raised with descriptions for helping 
to identify where the assertion failed. Also, each assertion 
may be raised with parameters for helping to identify why 
the assertion failed. In one embodiment, two types of 
assertion classes may be provided. In such an embodiment, 

35 one of the assertion classes may implement assertion- 
checking logic and the other assertion class may implement 
only null operations, with one of the assertion classes being 
selected to be raised. 

Every operation has a set of preconditions and postcon- 

40 ditions that must be met for the operation to be considered 
successful. If these expectations are not met, the system state 
is in error. How can operations check for these errors so that 
the handling of these critical errors are consistent across the 
application? 

45 Methods typically obtain and return a value, set an 
attribute based on a passed in parameter, or modify the state 
of the application based on some complex business rule or 
ruleset. While there is always some expected result of the 
invocation of an operation, there are also other, less expected 

50 possibilities. The provided parameters may not be within the 
expected range, thereby causing an error. A communications 
failure could cause the operation to fail to complete or, 
worse yet, return incorrect data or leave the system in an 
inconsistent state. 

55 Any complete design determines that some formal speci- 
fication is required to ensure operations complete correctly. 
This specification is most often in the form or pre- and 
post-conditions. These conditions define a set of logical 
expressions that must hold true for the operation to begin 

60 and end as expected. These conditions are usually defined 
during the Design Phase of development. An example is 
shown in the Operation Diagram below: 

FIG. 137 illustrates an operation diagram depicting an 
example of pre-conditions 13700 and post-conditions 

65 13702. 

The conditions, in short, define the contract for the 
method. All of these pre-conditions must hold true before an 
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operation's execution and all of the post-conditions must 
hold true after an operation's execution. Only then is the 
operation said to be successful. If any of these conditions 
fail, a critical error has occurred. The system must assume 
it is in an inconsistent state and cannot continue processing. 

It is expected that the system programmers will check for 
pre- and post-conditions systematically in the operations 
they are coding. This seemingly simple requirement 
becomes non-trivial when some issues are considered: 

How can multiple developers implement these checks in 
a consistent manner? 

Some condition checks may be expensive to complete 
(database and remote component queries). How can these be 
turned on and off to meet performance expectations? Prob- 
lem with deferred evaluation; see below. 

How can the exceptions raised when a condition check 
fails be handled in a consistent manner throughout the 
system? 

Therefore, a type of object should be developed to rep- 
resent a check against an operation's conditions. This 
generic class of objects is known as an Assertion. Applica- 
tion developers should then raise Assertions throughout the 
system to check the correctness of the code and system state. 

An Assertion accepts conditions that must always evalu- 
ate to true. If any of these conditions ever fail, a critical error 
has occurred and the system should shut down. Pre- 
conditions and post-conditions are good examples of the 
type of conditions that should be asserted during an opera- 
tion's execution. 

The Assertion class is passed a condition that, if evaluated 
to be false, raises the appropriate errors and shuts the system 
down. The purpose of this pattern is to formally recognize 
the pre- and post-conditions of a method in the actual code 
rather than through developer comments. By implementing 
an assert( ) method on a common superclass, the interaction 
with the Assertion class can be hidden from the functional 
developer. An example of the use of assertions is shown 
below: 
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if (!Asscrtion.isPcrformanccScnsitivc( )) 
{ 

// assert! 

} 



All operations will have both pre- and post-conditions. 
Even in cases where an operation defines an input parameter 

10 as something as broad as an integer, it is doubtful that all 
integers are acceptable to the operation. In this case, an 
Assertion should be raised to check if the parameter is in the 
appropriate range. 
A "top-level" error handler should be defined to catch all 

15 AssertionExceptions and handle them in a clean and con- 
sistent manner. This should include reporting the assertion 
failure and shutting down the system following an orderly 
procedure. 

It is important to note the difference between assertions 
20 and standard error-handling. Assertions are condition checks 
that can be turned on and off during runtime whereas 
standard error handling is always enabled. This is because 
assertions must always be true. The burden is on the testing 
process to catch all failed assertions. Thus, a failed assertion 
25 should simply never happen in deployed code. However, 
exceptions can happen, and therefore cannot simply be 
turned off. 
Benefits 

Ease of Error Identification, Many error are caused by 
30 invoking an operation with improper data (parameters). 
By formalizing these conditions, it is very obvious is an 
error was caused by bad data or bad code. 
Correctness. Properly placed assertions assure that the 
system is in a correct state and responses can be trusted. 
35 Assertion checking complements, but does not replace, 
a comprehensive testing program. The responsibility 
remains with the designer to identify the correct con- 
ditions to assert. 



public Customer creatCustomer(int newCustomerNumber) 
{ 

Customer newCustomer - null; // declare the new customer 
this.assert(newldentifier > 0);// pre-condition, a customer's 

// identifier must be greater than 

// zero 

// code to create the customer 

this.assert(newCustomer !» null); // post-condition, the customer 

was 

// created 

return newCustomer; 

} 



Assertions can be raised with descriptions and param- 
eters. A description can help to identify where the Assertion 
failed and a parameter list can help to identify why the 
Assertion failed. 

60 

Assertions should be raised at the beginning and end of 
every operation. Prior to raising the Assertion, a check 
should be made to see if it appropriate to raise one. (if 
assertions are enabled, if performance sensitive assertions 65 
are enabled). This can be accomplished by querying the 
Assertion class for its state before checking the assertion: 



Consistency. All checks will be made and handled in a 
similar fashion. 

Control. The enabling and disabling features of the Asser- 
tion allows an operations controller to determine when 
and what checks should be made at runtime rather then 
development time. 

Flexibility. All handling and clean-up of incorrect asser- 
tions is located in one place making changes to this 
logic much easier to implement. 

Readability. Polices concerning how assertions are actu- 
ally thrown and handled is not in the functional code. 
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Documentation. The code actually documents the design 
assumptions. This can also be used by documentation 
generators which read through the code. 
The Assertion class can be defined as shown in the 
following specification: 
Class Assertion 

void raise(boolean condition) throws AssertionExcep- 
tion 

void raise(boolean condition, String description) 

throws AssertionException 
void raise(boolean condition, Vector parameters) 

throws AssertionException 
void raise(boolean condition, Vector parameters, String 

description) throws AssertionException 
boolean isEnabled( ) 

boolean isPerformanceSensitiveEnabled( ) 
Class AssertionException extends Exception 
One possibility on how to handle the enabling and dis- 
abling of assertion checking would be to have two possible 
types of Assertion class. One which implements the actual 
assertion-checking logic and another which only imple- 
ments no-ops. The Assertion instance is then obtains through 
an AssertionFactory which can be set as to which of the two 
types to distribute. These settings are determined at runtime. 

It should also be noted that in Java, the exception that is 
thrown should be a generic run-time exception that doesn't 
need to be caught by the method or mentioned in the 
method's throw clause. 
Collaborations 
Factory 

Distributed Garbage Collection 

FIG. 138 illustrates a flowchart for a method 13800 for 
detecting an orphaned server context. A collection of out- 
standing server objects is maintained and a list of contexts 
is created for each of the outstanding server objects in 
operations 13802 and 13804. A compilation of clients who 
are interested in each of the outstanding server objects are 
added to the list in operation 13806. Recorded on the list in 
operation 13808 is a duration of time since the clients 
invoked a method accessing each of the contexts of the 
outstanding server objects. The list is examined at predeter- 
mined intervals for determining whether a predetermined 
amount of time has passed since each of the objects has been 
accessed in operation 13810. Contexts that have not been 
accessed in the predetermined amount of time are selected in 
operation 13812 and information is sent to the clients 
identifying the contexts that have not been accessed in the 
predetermined amount of time in operation 13814. 

After waiting a preselected amount of time for receiving 
a response from one of the clients, the context may option- 
ally be deleted if a response from one of the clients is not 
received within the predetermined amount of time. Also, a 
response may optionally be received from one of the clients 
requesting that one of the contexts be maintained. In such a 
situation, upon receipt of the response, a time the context 
was last updated may be updated to a current time. 

As a further option, a queuing delay may be accommo- 
dated for a response from the clients. Also, each of the 
clients may maintain a collection of all objects the client is 
interested in. The clients then may send requests to keep 
alive any objects the clients are currently interested in. 

A client requests a server process but due to abnormal 
circumstances fails to clean up. How is the orphaned process 
detected and removed? 

In the design of a stateful server, the LUW Context pattern 
facilitates the server process constructing domain objects at 
the request of the clients and maintaining these objects 
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within a given context. Domain objects are entered into a 
registry with their appropriate context which the server 
maintains and updates when a request is received to create 
or delete an object. Each time a context is accessed then a 

5 notification is broadcast to the registry, regardless of a state 
change. With a simple context management, each time a 
context is referenced by a client a reference counter is 
incremented and similarly decrements when the reference is 
destroyed. Once the reference count returns to 0 then the 
context can be removed from the registry. 

If the context is not explicitly deleted by the client then it 
will remain in the registry as the server has no way of 
detecting that the context is orphaned. 

Even if the client application is rigorously designed to 
ensure all redundant contexts are deleted, an abnormal client 

15 event may result in its termination leaving an orphaned 
server context. 

FIG. 139 illustrates a Client 1 13900 that has instantiated 
A 13902 and C 13904, deletes C but fails to delete A. 
The server still has a reference counter greater than 1 even 

20 though the client is no longer interested. 

Therefore, Distributed Garbage Collection should be 
implemented to ensure that orphaned server contexts are 
deleted on the server. In the registry for the Garbage 
Collection the server maintains a collection of outstanding 

25 server objects and for each object a list of its contexts, the 
clients currently interested and the duration since a method 
was invoked upon a given context by a client. Periodically 
this list is examined to establish if any of the objects have not 
been accessed for some configurable time and are candidates 

30 for reaping. So, for example, a value of 5 minutes could 
serve as a default poll event or keep alive interval. If a 
candidate for a orphaned server process is identified then the 
clients are sent a message, requesting if they are still 
interested in the context. This might be performed by 

35 publishing an "is anyone interested" message to the regis- 
tered clients to establish if anyone is. interested in the object 
in its assigned context or by asking the clients explicitly 
depending on the nature of the architecture. 

The client side also maintains a collection of all of the 

40 objects that it is interested in. When it is queried, it instructs 
the server to keep alive any objects it has an interest in for 
which a query has been received. 

FIG. 140 illustrates a GarbageCollector 14000 requesting 
for interest in context A 14002. No responses are received 

45 from any clients so the server assumes it is orphaned and 
deletes it. 

If the period configured for a client to respond expires 
then the context is deleted. This accounts not only for an 
abnormal termination of the client but for failure of the client 

50 application to clean up. However, if a request is received 
from a client to maintain a context then the time the context 
was last accessed is updated to the current time and it 
remains in the Garbage Collection registry. 

FIG. 141 illustrates a GarbageCollector 14100 requesting 

55 for interest in context B 14102. Client 2 registers interest so 
the reaper updates the access time stamp and maintains B. 
Benefits 

Cleanup on the Server. Reduces the amount of redundant 
resources on the server to a minimum. This is espe- 
60 daily important if a stateful component is held in a 
transaction by a client and the architecture prevents 
additional clients from accessing it, e.g. with BEA's 
M3. 

Performance. Ensures that only the required contexts are 
65 maintained on the server, minimizing the work that the 
server is required lo do, especially during the cleanup 
process at the end of a LUW. 
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Centralization. The collector has a central view over all of 
the contexts that are currently accessed by all of the 
clients within a given context. This simplifies the 
persistence of a context at the end of processing. 

In order to prevent potential race conditions the client 
must be given sufficient time to respond to the keep alive 
message from the server before the context is deleted. 
Typically the client has a separate listener for upward 
messages originating at the server, so queuing is not an issue 
at the client end. However, a server is more likely to queue 
on the receiving end, especially in a system with high 
message rates. 

Unless there is a dedicated listener on the server it must 
be configured to accommodate for any queuing delay on 
receipt of the client response. 
Collaborates With 

Context Pattern Language describes the architecture that is 
required before the Distributed Garbage Collection is 
required. 
Variation Of 

Java Shared Namespaces with distributed garbage collec- 
tion. 

Objectstore PSE WeakArrays. 
Exception Hierarchies 

FIG. 142 illustrates a flowchart for a method 14200 for 
creating a common interface for exception handling. Nam- 
ing conventions of exceptions are determined in operation 
14202. A prefix and/or a suffix is added to each exception 
interface name in operation 14204 for indicating that the 
exception interface is an exception. In operations 14206 and 
14208, where an exception error occurred is indicated and a 
determination is made as to what caused the exception error. 
Context is provided as to what was happening when the 
exception error occurred in operation 14210. Streaming of 
the exception is allowed to a common interface in operation 
14212. An error message is outputted indicating that an 
exception error has occurred in operation 14214. 

As an option, a layer and/or domain may be added from 
which each exception originates to each of the names of the 
exception interfaces. As another option, the exceptions may 
be partitioned into classes based on the way exceptions are 
handled, exceptions associated with different layers of a 
system, domains, and/or the source of the exceptions. As a 
further option, a class may be created which represents a 
source of the exception and holds an original copy of the 
exception for avoiding creation of duplicate exceptions. 
Also, arbitrary exceptions may each optionally support a 
clone method which creates a copy of the arbitrary excep- 
tion. 

Developing exception handling logic without classifying 
and organizing exceptions makes the handling logic cum- 
bersome and fragile to change. How should exceptions be 
structured? 

The traditional way of conveying errors is by passing 
error codes from callee to caller. This approach is adequate 
in some cases, but in general, it is less powerful and more 
error prone than an exception based approach. In the tradi- 
tional approach, only minimal information can be passed, 
such as a failure to locate a configuration file (information on 
which file has to be provided by some other means). It is also 
very easy, and common, to ignore the return code. Projects 
which faithfully test every return code end up mixing a high 
percentage of error logic with the primary logic. This 
increases the complexity, and the development, review, and 
maintenance effort. 

Some computer languages (Java, C++) support an error 
reporting mechanism based on exceptions. In these lan- 
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guages an exception can be a class type and hold arbitrary 
information, such as the name of the configuration file that 
was missing. Also, exceptions cannot be as easily ignored as 
return codes. If the callee raises an exception and the caller 
5 doesn't handle it, the caller's caller is checked to see if it 
handles the exception. This continues until the exception is 
handled or the program terminates. Designed properly, the 
error handling logic will be somewhat separated from the 
primary logic and will be less dense than the traditional 
approach. 

The exception class designer is free to create any interface 
for the class, and each exception class can have its own 
unique interface. The exception handling logic 14300 will 
know which exception 14302 was raised (via runtime 
support) and can make use of the interface particular to the 

15 given exception. You can think of the exception handling 
logic being a set of "chunks" of logic where each chunk 
handles a specific type of exception. With this in mind, you 
can see how having many different exception types will 
cause the exception handling logic to grow. As a new 

20 exception type is added to the system, a new "chunk" might 
have to be added to the handling logic. This is not good. The 
code is not flexible to change and is in several places. Note 
FIG. 143. 

Suppose you have all these chunks of handling logic and 

25 discover that the logic is pretty much the same. For example, 
assume your architecture is layered and you want to treat all 
exceptions from the persistence layer the same, such as 
logging the error and notifying the user. Also assume that the 
persistence layer can raise any one of fifty exceptions, and 

30 more are expected to be added in the future. This is fifty 
chunks of code that must be present in the exception 
handling logic, and again, this logic may be in several 
places. Wouldn't it be nice to write one chunk of handling 
logic and be done with it? 

35 Let's take another scenario. Suppose you want to prevent 
any raised exception from bringing down your system, as 
least not without a fight. In some cases the error will be 
unrecoverable and there is not much you can do but release 
resources (locks, communication channels, , . . ) and termi- 

40 nate. What caused the problem is going to be on the tops of 
the minds of the production support people, and yours when 
you get their call (always in the middle of the night). You 
could write the exception handling logic chunks for each 
exception type — remembering that each exception has its 

45 own interface and will require separate logic to handle each 
interface — for each exception, but now you have to handle 
all the exceptions in the system. Wouldn't it be nice to write 
one chunk of handling logic and be done with it? 

Therefore, to simplify the error handling logic and be able 

50 to treat groups of exceptions the same, a few techniques 
should be used to organize and define the exception inter- 
faces. 

The first step is to create an exception interface that all 
other interfaces will use or extend. It is not possible to 
5 5 provide one here as it greatly depends on the requirements 
at hand. But here are some guidelines: 

Determine the exception naming conventions. Use either 
a prefix or suffix to indicate that the interface is an 
exception. Also consider naming exceptions with the 
60 layer or domain they originate from. For example you 
may have an exception, CaAddressExcp, which is 
owned by the Customer Acquisition domain. 
Provide a means to determine where the error occurred 
(file, line, client or server, layer, . . . ) so that it can be 
65 investigated. 

Provide a means to determine what happened (could not 
open file: XYZ). 
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Provide context as to what was happening (Saving 

account information). 
Provide a way to stream the exception or stringify it. 
Consider separate production messages versus debug 

messages. 

Don't try to indicate severity. This is determined by the 
context of the caller, not the callee. 

The intent is to be able to handle any arbitrary exception 
the same by having a common interface. Take time and get 
this right, to avoid updating several other exceptions later. 

Now that this base exception interface is available, any 
handling logic can treat all exceptions alike; only one chunk 
of logic needs to be written. Specific exceptions can still be 
handled on a case by case basis as required. You can extend 
this concept to further partition the exceptions by creating a 
tree of exception types. By handling any exceptions at 
particular point in the tree, you effectively handle all excep- 
tion types below that point. The trick is in creating a useful 
tree. Here are some guidelines: 

Determine where handlers will be put and how they will 
respond to each exception. If you find that many are handled 
in the same way there may be a natural grouping that can be 
leveraged. 

Consider the stability of your grouping. Is the group 
cohesive or is regrouping likely? 

If parts of your system are layered, consider a branch that 
consolidates each layer. This enables a handler to deal with 
all exceptions emanating from a given layer. 

Consider grouping by domains (Legal, Finance). 

Consider grouping by subsystem 

Consider common problems such as parameter validation, 
pre- and post-conditions 

Consider the source (client or server). 

FIG, 144 illustrates that groupings are not always exclu- 
sive. It is possible to group some exceptions 14400,14402, 
14404 by layer and then domains within that layer. 
Benefits 

Simplicity. Simplifies handling logic by being able to 
write a handler that deals with the base exception type. 

Consistency. Consistent approach to error handling. 

Maintainability. Minimizes coding changes by reducing 
the multiple number error handling chunks. 

Manageability. Provides Conceptual Framework 

The solution section covered many of the considerations 
in creating the exception tree so this section only provides 
some additional details to consider. 

Wrapping and delegation can be used to simplify in 
certain situations. Consider a distributed application 
and the need or desire to handle server and client 
exceptions differently, or to know the source of the 
error. One way to avoid creating duplicate exceptions 
(one per source) is to create a class which represents the 
source and holds the original exception. For example 
AaServerExcp can hold a pointer to the base class 
AaExcp. The handling logic can catch AaServerExcp 
exceptions and then access the held exception. An 
alternative is to put a code in the base class with 
indicates source but then all logic needs to know to set 
this value and all handling logic needs to test for it. 

To hold onto an arbitrary exception you need a way of 
creating a copy of it, but you may not know the actual 
type of the exception. In C++ the exception will be 
destroyed when you leave the handling logic, so you 
need the ability to create a copy to hold onto. A 
common technique is it have all exceptions support a 
"clone" method which creates a copy of themselves. 
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Consider how to stream an exception so it can be sent 
from server to client. 
Exception Response Table 

FIG. 145 illustrates a flowchart for a method 14500 for 
recording exception handling requirements for maintaining 
a consistent error handling approach. An exception response 
table is provided in which an exception is recorded in 
operations 14502 and 14504. The context of the exception is 

10 entered in the exception response table in operation 14506 
and a response for the exception is listed in the exception 
response table in operation 14508. The response is subse- 
quently outputted upon the exception occurring in the con- 
text in operation 14510. 

15 A typical response and a last resort response may be listed 
in the exception response table. The typical response may 
also be outputted upon the exception occurring in the 
context. The last resort response may be outputted upon the 
exception occurring out of the context. Additionally, abbre- 
viations may be used to reduce an output size of the 
exception response table. Further, the exception response 
table may also include an exception category field for 
permitting organizing multiple exceptions by source. 

25 Optionally, an optimization may be determined that can be 
made based on similar entries in the exception response 
table. Further, the optimization made may also include 
classifying the exceptions for organizational purposes. 
The response to an exception may vary per exception type 

30 and the context in which it is thrown, such as being thrown 
on the client or server, and the context in which it is handled. 
How do you record the exception handling requirements? 

During exception handling design there are several 
aspects to capture to achieve a consistent approach: 

The set of exceptions to be handled 
The set of responses to these exceptions 
The context in which the exception is handled; e.g. client 
or server, batch or GUI 
40 The set of exceptions to handle and their organization 
structure varies by project. Topically exceptions are orga- 
nized into hierarchies to facilitate handling. The response to 
an exception may vary by exception type, the context in 
which it was thrown, and the context in which is handled. 
45 Here are some examples of error handling decisions of a 
hypothetical project: 
"All exceptions thrown on the server, and not handled by 

the server logic, will be propagated to the client." 
"The current transaction is aborted if a server exception is 
50 not recoverable" 

"All Server exceptions derived from Excp will be logged 
if not handled by the server code. The last resort 
handler will ensure this." 
55 "GUI clients will display the error information in a splitter 
window" 

"Batch clients will send error information to Operations" 
These few examples demonstrate how context (Batch, 

GUI, Client, Server, last resort) can affect the handling of 
60 exceptions, and that even in a given context, the exception 

type may play a role in the handling. In a real system there 

may be several other context and exception-type specific 

requirements. 

There are two common exception handling contexts that 
65 should be present in most systems. One is referred to as the 
Typical Response and the other is referred to as the Last 
Resort Response. The Typical Response is the error handling 
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code intentionally added to handle exceptions. For example, 
car.start( ) is likely to fail due to being out of gas. The 
Typical Response may be to fill the tank and retry. The Last 
Resort Response is what to do when an exception is not 
handled (the Typical Response could not handle the error, 
such as a hole in the gas tank). Last Resort Response is a 
way of capturing what should be done when application 
code fails to handle an error. Recovery is usually not 
possible at this point but the handler may be coded to log the 
error and notify Operations of the problem. Without this 
response, systems may crash unnecessarily, or without indi- 
cating what happened. 

All these permutations of exception types, contexts, and 
responses need to be managed in order to maintain a 
consistent error handling approach. 

Therefore, use an Exception Response Table to capture 
the exceptions in the system, and the appropriate responses 
by context. What is important to capture is the exception, 
context, response, information; documenting the error han- 
dling requirements. 

The following table lists exceptions by category and type, 
with the typical and last resort response. Other contexts and 
responses are listed within these columns. The exception 
category field is optional but can help to organize exceptions 
by their source (application, architecture, . . . ) or hierarchy. 
This table can become quite packed with response informa- 
tion so a nomenclature may need to be developed to con- 
dense the information. The implementation section provides 
an example of this; Other ways of formatting this informa- 
tion are possible. 



Exception 



Typical 
Response 



Last Resort 
Response 



Exception Category 

Exception-Name 
Description 

Exception Category 

Exception-Name 
Description 



Benefits 

Requirements Traceability. Exceptions requirements are 
captured and managed through implementation. 

Hierarchy Design. Analysis may show optimizations that 
can be made such as handling a subtree of exceptions 
with the same code, as the response is the same to any 
exception in the subtree. 

Interface Design. Discovery of interface requirements on 
the exception classes to support a particular response is 
another benefit. 

Handler design. Assists in exception handling design by 
identifying common responses that can be leveraged by 
the handlers. 

The table below shows an example of an Exception 
Response Table for a fictitious client/server system. This is 
followed by the nomenclature section which is customized 
per project. 



20 



25 



30 



35 



45 



50 



55 
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Name 



Typical Response Last Resort Response 



Architecture Framework 
Exceptions 

AaAssertionExcp 

Assertion failure 



10 



AaExcp 

Base class for exceptions 
Application Exceptions 

Ca Bala nee Excp 
Account out of balance 



C: N/A 
S: N/A 



C:N/A 
S: N/A 



C: L, Popup(severe), 
Shutdown 

S: L, N, 

P(AaServerAaExqp), 
Shutdown 
C: N/A 
S: N/A 



C: Popup(warn) C: L, Popup(warn) 
S: S: L, N, 

P(AaServer AaExcp) P(AaServer AaExcp) 



Nomenclature 

Note: Abbreviations were used so that the table could be 
printed. The nomenclature section is only meant to serve as 
an example. 
Context 

OClient 

S=Server 
Response 

N/A»not applicable; don't handle 

L=log error 

L(diagnostic)=log errors for diagnostic purposes only 
N»notify operations 

Optional=application, context dependent. Not required to 

be caught 
P»pass exception to client 

P(<exception>)=pass given exception type to client, will 

be different from type caught 
Popup(warn)=display warning message 
Popup(severe)=display severe warning message 
Popup(retry)=display retry message 
Shutdown-release resources and shutdown gracefully. 
Exception Hierarchy discusses how to organize excep- 
tions. 

Last Resort Exception Handling describes where handlers 
should be placed to prevent a program from terminating 
without warning. 

Polymorphic Exception Handler describes how to design 
and code exception handlers that reduce the impact of 
changes and the overall size of the error handling logic. 
Polymorphic Exception Handler 

FIG. 146 illustrates a flowchart for a method 14600 for 
minimizing the amount of changes that need to be made to 
exception handling logic when new exceptions are added. 
Exceptions are organized into hierarchies in a polymorphic 
exception handler in operation 14602. A root of one of the 
hierarchies in which an exception occurs is caught in opera- 
tion 14604. The exception is instructed to rethrow itself in 
operation 14606. The rethrown exception is caught and 
identified in operations 14608 and 14610. A type of the 
rethrown exception is determined in operation 14612 and a 
message is outputted indicating the type of the rethrown 
exception in operation 14614. 

Single exception interfaces may be used as the roots of the 
hierarchies. Also, the polymorphic exception handler may 
handle each unique root. Further, an added exception may be 
organized into a hierarchy and handled by the polymorphic 
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exception handler. As an option, handling behavior may be 
encapsulated in the polymorphic exception handler. As 
additional option, catch blocks may also be created to catch 
the rethrown exception. 

Large systems can be quite complex and require error 
management integrating disparate components and/or librar- 
ies (i.e. DBMS APIs, data structures library, middleware, 
etc) How can exception handling logic be written so that 
little or no changes are required when new exceptions are 
added to the system? 

A software system using exceptions as the error handling 
approach may have to respond to a variety of exceptions. 
Handling each exception type on a case by case basis is 
cumbersome and expensive, both in terms of initial devel- 
opment and subsequent maintenance. In languages such as 
Java and C++, the mechanism to handle exceptions is to use 
try -catch blocks which look like this: 



// perform some work here 



10 



15 



20 



25 
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try 
{ 

} 

catch (ExceptionTypeA& excp) 
{ 

// Exception A thrown. Handling logic here 

} 

catch (ExceptionTypeB& excp) 
{ 

// Exception B thrown. Handling logic here 

catch (...) 30 
{ 

// Don't know what was thrown, but still need to handle it. 

} 



This example shows only two explicit exception types 35 
being handled but a system typically has several potential 
exceptions. If the development of the exception types is 
poorly designed the try-catch blocks can become quite large 
as they attempt to handle each exception. Imagine trying to 
handle, say, fifty more exception types, in several places, in 40 
the code. The error handling code expansion is exponential! 
FIG. 147 depicts a program 14700 (i.e., the exception 
handler of the present invention) with a few try -catch blocks 
14702. As more exceptions are added these blocks expand to 
handle each new exception. 45 

Another problem with exception handling logic is that it 
can be quite involved, such as logging the information to a 
persistent store, notifying Operations support, rolling back a 
transaction, etc. the example only showed one commented 
line to represent the code. Again, imagine each catch block 50 
requiring several lines of code. This logic may be repeated 
in each catch block. 

Taken together, varying exception types and potentially 
repeating and complex logic in the catch blocks, the devel- 
opment and maintenance efforts regarding error handling are 55 
going to be much more expensive than they need to be. 

Therefore, structure the exceptions into hierarchies, create 
an exception handler object that performs the catch block 
logic, and minimize the number of catch blocks required to 
support a given try-block. 60 

Exception Hierarchies organizes exceptions into hierar- 
chies and facilitates the design of exception handlers. Han- 
dlers can then be designed to handle the roots of hierarchies. 
This is much simpler than handling each exception type on 
a case by case basis. In custom development where the 65 
project has control of all code, a single exception interface 
can be used as the root. The more likely situation is some 



custom development and using third party libraries which 
may also use exceptions. In these cases, the exception 
handler will handle each unique root. 

Using an exception handler, versus custom logic per catch 
block, reduces the maintenance and development effort as 
the code is easier to read, there is less of it, and any changes 
that need to be made can be made in one place. 

The following code snippet shows the form of the try- 
catch blocks using the polymorphic exception handler. It 
may seem equivalent to the prior catch-block example but it 
is not. The first distinction is the type of exceptions handled. 
In this case, the roots of the exception hierarchies are caught, 
not the individual exception types. For this example there 
are only two exception hierarchies in the system, so only 
these roots are handled. What this means is that as new 
exceptions are added to the hierarchies, this code does not 
change, and remember, this code is in several places in the 
system. 

The second difference with this code is the encapsulation 
of the handling behavior in the exception handler. The 
handle method can perform arbitrarily complex logic behind 
the scenes, and if this needs to change, is changed in one 
place. For example, if the current handling logic logs a 
message to disk and now needs to be extended to notify 
Operations personnel, this can be centralized in on place. 
The code as written does not need to change. 



try 
{ 

} 



// perform some work here 



catch (Exception Root& excp) 



{ 



ExcpHdlr hdlr; 

hdlr.handle(excp); 



} 

catch (rhirdPartyRoot& excp) 
{ 

ExcpHdlr hdlr; 

hdlr. hand! e(excp); 

} 

catch (...) 
{ 

ExcpHdlr hdlr; 
hdlr.handle( ); 

} 



FIG. 148 depicts the same program 14800 (the polymor- 
phic exception handler) with smaller catch blocks 14802. A 
handler 14802 has been added which consolidates the com- 
mon code and the number of catch blocks has been reduced 
overall by making the handler responsible for handling each 
exception. The downside is that now the handler is subject 
to frequent change as exceptions are added to the system. 
The maintenance effort outweighs this disadvantage. 

The examples have shown a single exception handler 
being used. In practice it is more likely that multiple will be 
used. For example, the exception handler on a server may 
have different requirements or constraints than a client, or 
one client may be GUI based and display pop -up error 
messages, where another client is a batch program that needs 
to send notification messages to Operations. This can be 
handled by creating multiple handlers or using the Strategy 
pattern to customize the behavior. 
Benefits 

Simplicity. Reduces development and maintenance effort 

required for exception handling 
Maintainability. Reduces impact of changes 
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Robustness. Centralizes/Encapsulates handling logic 

Flexibility. Multiple handlers can be used 

The exception base class declares a method, rethrow, 
which is used by the handler to determine the real type of the 
exception. Another approach is to use double dispatch which 
may be show in a future version. Below is an example of this 
interface only showing the essential detail. 



//- 

//-Base Class of Exceptions 

class Excp 
{ 

public: 

//-Rethrow the exception. Throw •this; 
virtual void rcthrow( ) const = 0; 

}; 

// 

//-Example Derived Class of Exceptions 

// _ 

class Derived : public Excp 
{ 

public: 

virtual void rethrow( ) const { throw "this; } 

// 

//-Example Derived Class of Exceptions 

// 

class Sub Derived : public Derived 
{ 

public: 

virtual void rethrow( ) const { throw "this; } 

}; 



When the exception handler is passed the exception from 
the catch-block all it knows it that it has a root exception 
type. For some projects this may be sufficient if the excep- 
tion interface is rich enough and all exceptions are treated 
the same. In other cases, exceptions may require specialized 
treatment. With the rethrow mechanism in place, the handler 
can create a try -catch block and have the exception rethrow 
itself. The catch blocks are then used to catch the specific 
exception type. 



//- 

//-Exception 
Handler 

class ExceptionHandler 
{ 

public: 

Exception Handler( ); 

//-Handle the root exception 

void handle (const Excp& ); 

//-Handle a third party root 

void handle(const ThirdPartyExcp& ); 

// - - - 

//-Handle the exception 

// 

void ExceptionHandler: :handlc(const Excp& e) 

//-Rethrow the exception to get the specific type 
//-Note that catches are in the order of most specific to 
//-most general. 

try 
{ 

e.rethrow( ); 

} 

catch(SubDerived& excp) 
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-continued 

{ 

// Handle SubDerived 

5 } 

catch(Derived& excp) 
{ 

// Handle Derived 

} 

catch( . . . ) 
10 { 

// Handle e parameter here since nothing matched it. 
} 

} 

Exception Handler: :handle(const ThirdPartyExcp& e) 
{ 

15 // Handle based on Third Part yExcp interface 

//Can't rethrow because ThirdPartyExcp doesn't support this. 
// Could use RTTI if needed. 

} 



Load Balancer 

FIG. 149 illustrates a flowchart for a method 14900 for 
distributing incoming requests amongst server components 
for optimizing usage of resources. Incoming requests are 
received and stored in operations 14902 and 14904. An 
availability of server components is determined and a listing 

25 of available server components is compiled in operations 
14906 and 14908. A determination is made as to which 
server component on the listing of available server compo- 
nents is most appropriate to receive a particular request in 
operation 14910. Each particular request is sent to the 

30 selected server component determined to be most appropri- 
ate to receive the particular request in operation 14912. 

Optionally, the determination of which server component 
is the most appropriate may be performed by allocating the 
requests on a round-robin basis whereby requests are 

3 5 assigned to consecutive server components by traversing 
along the listing of available server components. As another 
option, the determination of which server component is the 
most appropriate may also include calculating an amount of 
utilization that each available server component is currently 
experiencing. 

40 The amount of utilization of each available server com- 
ponents may be calculated based on current CPU utilization, 
kernel scheduling run-queue length, current network traffic 
at a node to the server component, and/or a number of 
requests currently being serviced. Also, a request may be 

45 rerouted to a different available server component upon a 
crash of the selected server component. Additionally, the 
server components may be saved in a persistent store, 
wherein a check is made to determine whether a connection 
to a server component needs to be reestablished. 

50 In order to support scalability in a high volume distributed 
component environment, resources tend to be replicated. 
How can incoming requests be distributed amongst the 
available server components in order to optimize the usage 
of system resources? 

55 In a distributed system, server components provide func- 
tions and data that can be accessed by client components. 
Many identical copies of a server component can be running 
on different platforms in the system in order to support large 
volumes of client requests. 

60 In order to make use of the system's scarce resources, 
some way of routing an incoming request to the best server 
component available is required. In general, all requests take 
a similar length of time to service. 

FIG. 150 illustrates server components 15000 receiving 

65 service requests 15002. 

Therefore, use Load Balancer to select the best server 
component out of an available pool for the client to use. 
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FIG. 151 illustrates a load balancer 15100 mediating the 
requests of FIG. 150. 

Incoming client requests are routed by the Load Balancer 
to the best available server component. 

A number of possible strategies exist for deciding which 
server component is the most appropriate at a given point in 
time. 

Round Robin — Allocate the received requests on a round- 
robin basis, whereby a list of the available server 
components is created and, as requests are received, 
they are allocated by traversing down the list. When the 
end of the list is reached, the next request is allocated 
to the server component at the beginning of the list. 

Utilization Based — Allocate the received requests based 
on the utilization that each server component is cur- 
rently experiencing. The definition of utilization can be 
tailored to meet specific requirements or deployment 
strategies. It may be based on a combination of current 
CPU utilization, kernel scheduling run-queue length, 
current network traffic at that node, number of requests 
currently being serviced, or any other factors particular 
to the environment. 
Benefits 

Performance. Based on the selection strategy employed, 

the client is connected to the server component that is 

best able to serve it. 
Scalability. As the number of users and requests increase, 

processing can be distributed across the available 

resources. 

Robustness. In the event of the server crashing, the client 
can then ask the Load Balancer to provide another 
server component for it to use. This can be extended 
still further by federating Load Balancers and their 
associated server component pools. 
The following is the IDLthat was used to define the Load 
Balancer: 



interface Load Balancer 
{ 

Object ge (Service ( ) 

raises ( Architecture Exception ); 
void register ( in Object aServerComponent ) 

raises ( Architecture Exception ); 

}; 



Collaborations 

Round Robin Load Balancing 

Utilization Based Load Balancing 
User Context 

FIG. 152 illustrates a flowchart for a method 15200 for 
maintaining a security profile throughout nested service 
invocations on distributed components. In operation 15202, 
interconnections are provided between distributed compo- 
nents each having nested service invocations. A user is 
identified in operation 15204, The user is associated with 
roles in operation 15206. In operation 15208, a user context 
instance is created upon successful identification of the user. 
The user context instance also includes information about 
the user including the roles. A request is received from the 
user to invoke a service on a component in operation 15210. 
The component invokes an additional service of another 
component. The user context is queried for the information 
about the user in operation 15212. The user information is 
compared with an access control list for verifying that the 
user has access to the component in operation 15214. The 
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user information is also compared with an access control list 
for verifying that the user has access to the additional service 
of the other component in operation 15216. 

Optionally, all user interactions may be logged as well. As 

5 another option, a user interface may be modified to provide 
access to actions that can be performed by the user based on 
an identity of the user and the roles associated with the user. 
The user context instance may also be passed along as a 
parameter of service invocations. Additionally, the service 

10 invoked may associate any objects created, updated, or 
deleted with the user context instance. As a further option, 
the user context instance may also encapsulate security 
certificates of the user. 

For security and auditing purposes, user information must 

is be maintained throughout a service's implementation across 
multiple, distributed platforms. How can this original secu- 
rity profile be maintained throughout nested service invo- 
cations on distributed components? 

All mission-critical systems require some form of security 

20 and auditing capabilities. These capabilities restrict who can 
use the system and what they can and cannot do and, in the 
case of a security breach or dispute, resolve who did what 
and when. 

To meet these capabilities, users must be identified, 

25 associated with roles and granted authorization before any 
operation proceeds. In addition, all user interactions and 
results of those interactions may be logged. On a user 
interface, access to certain panels and controls are granted 
according to a user's role. 

30 In a distributed, component-based system, these complex 
requirements become even more difficult to implement. 
Typically, a client (or user) invokes some service on a 
component. That component may invoke any number of 
additional services on any number of additional components 

35 to complete its designated task. These successive service 
invocations are a result of the initial client request so the 
security profile that allowed the initial request must also 
allow all successive requests. 

FIG. 153 illustrates a component interaction diagram 

40 showing an interaction between a number of components in 
a financial system. A user initiates an addStock( ) service on 
the Portfolio component 15300. To perform the addStock( ) 
service, the Portfolio must use the getStockPrice( ) and the 
deductFromAccount( ) services on the Market and Finance 

45 components 15302,15304, respectively. This implies that a 
user who can access the addStock( ) service must also have 
permissions to access the getStockPrice( ) and the 
deductFromAccount( ) services. This may need to be 
checked by each of the distributed components within the 

50 context of one logical service. In addition, auditing what has 
been done, or perhaps requested to be done, adds another 
common requirement that must be accounted for. A compo- 
nent servicing multiple clients must associate client requests 
with corresponding services invoked on business objects. 

55 This information must be persisted as each change is com- 
mitted. 

Therefore, represent information about a user in a shared 
User Context object. This object maintains a user's unique 
identification that can be subsequently checked against a 

60 resource's access control list (ACL). A User Context 
instance is created upon a user's successful, validated iden- 
tification to the system (usually through some "login" 
mechanism). After that, the system user interface can modify 
itself to provide only the actions that can be performed by 

65 that particular user acting in a particular role. Controls may 
query the User Context and modify their own visual state as 
needed (enable/disable, hide/show). 
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The User Context can also be passed along as a parameter 
of service invocations. All public, stateless services on a 
component should provide for a User Context to be passed 
along as a parameter. The service being invoked can then 
associate any Business Objects created, updated, or deleted 
as a result of the service invocation with the User Context. 

One example of this would be a User Manager 15400 
associating a User Context instance 15402 with the Business 
Objects 15404 they are affecting. FIG. 154 illustrates a user 
manger/user context relationship diagram. 

These associations can be used for auditing purposes. 
When a change to a Business Object is committed, a log 
entry can be created tying the change with the user that 
triggered it. 
Benefits 

Common User Representation. One single representation 
of a user and their access rights can be shared across all 
areas of the system. 

Extensible Security. Because there is one source for the 
User Context various policies or strategies could be 
used to identity and authenticate the User within a 
context. For example, it could encapsulate the User's 
certificates that allow more advanced security strate- 
gies to determine authorization. 

Class UserContext 

UserContext(Identifier identifier) 
Identifier getldentifier( ) 
String getName( ) 
void setName(String newName) 
void addRight(String accessArea, AccessLevel level) 
void removeRight(String accessArea, AccessLevel 
level) 

Vector getRights(String accessArea) 
boolean canCreateIn(String accessArea) 
boolean canReadIn(String accessArea) 
boolean canUpdateIn(String accessArea) 
boolean canDeleteIn(String accessArea) 
Gass AccessLevel 
static AccessLevel create( ) 
static AccessLevel read( ) 
static AccessLevel update( ) 
static AccessLevel delete( ) 
boolean=(AccessLevel anAccessLevel) 
It is expected that the User Context will be passed from 
component to component. In this case the User Context will 
have to be defined using some sort of interface language 
definition (IDL). 
Collaborations 
Permission 
Policy 

SecurityManager 
Logging 
Alternatives 

MTS & EJB offer an environment that does not require 
the passing of the context with every operation. A container 
as a set <context typo that provides a handle within the 
component for the methods to access the cached context. 

Information Services Patterns 

Reliable information access mechanisms in a multi-user 
environment are a crucial, technical issue for almost all 
systems that a user builds. 

Most business information systems manage data which 
must be saved in non -volatile storage (e.g., disk). The data 
must live, or "persist," between invocations of any particular 
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application or program. Persistence is the capability to 
permanently store this data in its original or a modified state, 
until the information system purposely deletes it. Relational 
databases, object databases, or even flat files are all 
5 examples of persistent data stores. 

This section discusses issues and approaches for devel- 
oping an object-oriented persistence architecture. 

A key issue frequently encountered in the development of 
object-oriented systems is the mapping of objects in memory 
10 to data structures in persistent storage. When the persistent 
storage is an object-oriented database, this mapping is quite 
straightforward, being largely taken care of by the database 
management system. 

In the more common situation where the persistent stor- 
15 age is a relational database, there is a fundamental transla- 
tion problem or a so-called "impedance mismatch". The 
physical, logical, and even philosophical differences 
between a relational and object data storage approach are 
significant. Mapping between the two is hard. The architec- 
20 ture must, in this case, include mechanisms to deal with this 
impedance mismatch. 

The impedance mismatch is due to the following con- 
trasting features of objects/classes and tables: 
25 Identity: Objects have unique identity, regardless of their 
attributes. Tables rely on the notion of primary key to 
distinguish rows. While a relational DBMS guarantees 
uniqueness of rows with respect to primary keys for 
data stored in the database, the same is not true for data 
3Q in memory. 

Inheritance: This is a meaningful and important notion for 
classes; it is not meaningful for tables in traditional 
RDBMSs. 

Navigation: The natural way to access and perform func- 
35 tions on objects is navigational, i.e., it entails following 
references from objects to other related objects. By 
contrast, relational databases naturally support associa- 
tive access, i.e., queries on row attributes and the use of 
table joins. 

4Q The patterns in this section focus on problems and solu- 
tions associated with using a relational DBMS with an 
object-oriented persistence architecture. 

A key objective of a comprehensive object-to-relational 
persistence architecture is shielding the application business 
45 logic and developers from the relational structure. The 
benefits are a simplified environment for business 
developers, reduced distraction with technical issues, and 
increased focus on the business object model and functional 
logic. However, in order to reap these benefits, a significant 
50 investment in architecture development is typically required. 
The scope of a persistence architecture can range across 
the following levels of transparency and automation: 
Heavyweight, fully-automated, including the mapping of 
the object model to the database schema and generation 
55 of all the database access code. Variants of this archi- 
tecture type may allow the customization of database 
access code (e.g., for optimization purposes). 
Lightweight mechanism which provides generic persis- 
tence capabilities to business objects but delegates all 
60 database access to separately developed data access 
routines. In this case, the data access routines are not 
part of the persistence architecture per se. 
Minimal persistence approach in which each business 
object is directly responsible for database access 
65 Of course, there is a tradeoff between transparency, 
automation, and flexibility on the one hand, and architecture 
complexity and development cost on the other. 
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The patterns in this section solve several of the funda- 
mental problems encountered in the development of an 
object -to-relational persistence architecture, including the 
mapping of classes to tables (Data Handler, Individual 
Persistence), identity management (Object Identifiers as 
Object), caching(Object Identity Cache), allocation of 
responsibilities (Data Handler, Piecemeal Retrieval, Persis- 
tent State Separate from Persistent Object), and data access 
optimization (Multi-Object Fetch) and the mapping of basic 
SQL types to object attributes (Attribute Converter). 

In addition to providing persistence capabilities, reliable 
information access mechanisms in a multi-user environment 
must support transaction semantics. As the real-life imple- 
mentation of all of the patterns in this section requires 
integration with transaction management frameworks, the 
Persistence patterns should be considered and used in con- 
junction with the patterns in the Transactions section. 
Attribute Converter 

FIG. 155 illustrates a flowchart for a method 15500 for 
translating an object attribute to and from a database value. 
A database is provided and a conversion process is deter- 
mined for converting an object attribute to and from a 
database value in operations 15502 and 15504. The conver- 
sion process is encapsulated in an attribute converter. A first 
object attribute is directed to the attribute converter for 
conversion to a first database value in operation 15506. A 
second database value is directed to the attribute converter 
for conversion to a second object attribute in operation 
15508. 

A different attribute converter may be created for each 
type of conversion of object attributes to and from database 
values. In addition, the attribute converters may also imple- 
ment a common interface. Further, all attributes of the same 
type may be directed to a particular attribute converter. 
Optionally, a second attribute converter may be substituted 
for the attribute converter for altering the conversion of the 
attribute. As an another option, the attribute converter may 
be altered for relieving a performance bottleneck. 

Object attributes must go through some translation before 
they are written to and after they are read from some 
persistent stores. How can you isolate the translation algo- 
rithm from the persistent object and the persistence mecha- 
nism? 

When interacting with a relational data store, the attribute 
value doesn't always map directly to a database type. Other 
times, an attribute value maps to more than one database 
type. 

For example, in an Object based system, an attribute with 
a Boolean value is often converted from a Boolean object to 
a "T" or "F" string before it is saved in the database. In 
another example, a phone number attribute might be com- 
posed of an area code (847), an exchange (714) and an 
extension (2731). These three field might be saved in three 
separate database columns or combined into one before they 
are saved in the database. 

FIG. 156 illustrates that an attribute 15600 can't be saved 
directly into the persistent store 15602. 

An impedance mismatch exists between the attribute and 
the data store and a conversion must take place. 

The logic to perform this conversion can vary from one 
attribute to another. Based upon the attribute type, a different 
conversion must take place. In addition, special situations 
can arise where the same type of attribute will be stored 
differently in different situations. It is desirable to reuse this 
logic; however, the solution must be flexible enough that the 
developer is not locked into one single translation for an 
attribute type. 
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Therefore, use an Attribute Converter to translate data- 
base values to object attributes and vice versa. 

FIG. 157 illustrates the use of an Attribute Converter 
15700 to save an attribute 15702 into a database 15704. 

The knowledge of how to translate an attribute value to 
and from a persistent store is encapsulated in a separate 
Attribute Converter object. 

The attribute's value should not be obtained directly from 
( the attribute prior to saving it in the database. Nor should an 
attribute be instantiated directly from the raw value obtained 
from the persistent store. Values should be obtained or 
attributes created exclusively via an Attribute Converter. 

It is recommended that a different Converter be created 
15 for each type of conversion required. This keeps the Con- 
verter's knowledge very specialized. As a result, the com- 
bination of Converters required to persist an entire object to 
a persistent store is very flexible due to the modularity of the 
Attribute Converter objects. 
20 Benefits 

Reuse. For some types of attributes, the conversion pro- 
cess can be rather involved. If this knowledge is 
encapsulated in an Attribute Converter, it can be reused 
for converting other attributes of the same type. 
Flexibility. If the conversion for a specific attribute needs 
to be altered, simply substituting a different Attribute 
Converter will alter the behavior and not disrupt the 
rest of the application. 
30 Maintainability. Altering a single Attribute Converter can 
affect several attributes in the system. For instance, if 
the conversion of one specific type of attribute is 
identified as a performance bottleneck, altering the 
corresponding Converter can benefit a large part of the 
35 system. 

Ideally, all Attribute Converters should implement a com- 
mon abstract class or interface. This allows the architecture 
to treat all Converters equally. The architecture need not 
know the specific translator class it is using. 
40 The interface may look something like this. 



public interface AttributeConverter 

{ 

45 public String translate Value ForDataStore (Object anAttribute); 
public Object translatcValueFromDataStore(String aCohimn, 
java.sql.ResultSet aResultSet); 
} 



50 The first behavior, translate ValueForDataStore, takes an 
attribute and translates it into a String that can be used in an 
SQL statement. The second behavior, 
translateValueFromDataStore, takes a column name and 
JDBC result set as arguments. It then answers the attribute 

55 translated from the given result set. Each implementation of 
AttributeConverter must then implement both behaviors in 
their own specific way. 



public class BooleanTranslator implements AttributeConverter 
{ 

public String translate Value ForDataStore (Object anAttribute) 
{ 

String value - null; 
if (anAttribute !- null) 
{ 

i^((BooIean>nAttribute).boolean\Wue( )) 
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-continued 

{ 

value - W "T"; 

} 

else 
{ 

value = "'F M ; 

} 

} 

else 
{ 

value - "NULL"; 

} 

return value; 

} 

public Object translate ValueFromDataStore(String aColumn, 
java.sql.ResultSet aResultSet) 
{ 

Boolean result = null; 
String value = null; 

value = aResultSet.getString(aColumn); 

if(val ue .equals Igno reCase("T")) 

{ 

result » new Boolean (true); 

} 

else iff value. equals Igno reCase("F')) 
{ 

result - new Boolean(false); 

} 

return result; 

} 

} 



The Boolean Converter above knows how to translate a 
Boolean object to and from a character representation in the 
relational database. 
Collaborations 

Normalized Mapping — The Mapper contains all informa- 
tion required to store an object in a relational data store. 
Attribute Converter can be utilized by Normalized Mapping 
to store the knowledge needed to properly translate attribute 
state values to and from the persistent store. 

Denormalized Mapping — Denormalized Mapper is 
another pattern for mapping objects to a relational database. 
The Attribute Converter pattern could be used by Denor- 
malized Mapper to provide conversion between attribute 
values and database values. 
Alternatives 

Case Statements — Case statements aren't really a pattern, 
but they axe an alternative to Attribute Converter. A case 
statement could be implemented in the super class to handle 
the translation of the data. 
Data Handler 

FIG. 158 illustrates a flowchart for a method 15800 for 
controlling data. A data retrieval mechanism is provided in 
operation 15802 for retrieving data from a database. The 
data retrieval mechanism also writes data to the database. In 
operation 15804, the data retrieval mechanism is encapsu- 
lated in a data handler. A request from a domain object is 
received for a retrieval of a portion of the data in the 
database in operation 15806. The data retrieval mechanism 
is utilized in operation 15808 to retrieve the portion of the 
data from the database. The portion of the data is passed 
through the data handler to the domain object in operation 
15810. 

The data retrieval mechanism may be capable of being 
used by a plurality of domain objects. Also, the data retrieval 
mechanism may capable of being used by only one of a 
plurality of domain objects. Dependencies on the data 
retrieval mechanism within the data handler may also be 
managed via code generation. 
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The data handler may physically partitioned into a com- 
ponent separate from the domain object. Optionally, the 
domain object may write attributes to a data stream. In such 
a case, the data handler may define an order in which the 
5 attributes are written to the data stream. Also, a row class 
may define the attributes in the same order as the attributes 
appear on the database. Further, the data handler may iterate 
over the attributes and may save them to the database. 

Business Objects in memory generally store and retreive 
Q their data members from some type of persistent store. When 
using Individual Persistence, how can we ensure that the 
retrieval mechanism used by the domain object is indepen- 
dent of the business logic? 

Individual Persistence assigns responsibility for data 
access at the level of individual domain objects. Each 
15 domain object or class can retrieve, update, insert, and delete 
its data from a persistent store independently of other objects 
or classes. This promotes encapsulation and reuse across 
business transactions. 

FIG. 159 illustrates the data retrieval mechanism calls 
20 being placed directly within the domain object 15900 (in this 
example SQL is inserted into the Account business object). 

When persistence is at the class level, it is typical to code 
the actual SQL, serialization, or CICS call directly in the 
class itself. In the example shown above, an "Account" 
25 object can contain the SQL needed to retrieve and save its 
state to the database. 

This approach can reduce the flexibility of the domain 
object, in that, changes to the access logic or the backend 
database must result in changes to the business object or 
3Q class. How can we ensure that the business logic is inde- 
pendent of the data retrieval mechanism for such a class? 

FIG. 160 shows the interrelationship between a database 
16000, a persist 16002, and an account 16004. 
' Business objects delegate their data retrieval mechanism 
35 to an appropriate handler. This Data Handler can be either be 
generic or specific to each type of domain object used. To 
minimize the impact of changes, dependencies on the data- 
base schema or data retrieval mechanism within the handler 
could be managed via code generation. In this manner, the 
40 physical data access is separated from pure business logic. 

FIG. 161 illustrates that the database retrieval mechanism 
is separated from the business object 16100 by encapsulat- 
ing the logic within a data handler 16102. 
Benefits 

45 Loose Coupling of Data Access. The business object is 
independent of the database access logic and the back- 
end database. As a result, the method by which the 
domain object accesses the persistent store can be 
changed without impacting existing source code. 

50 Distribution. Data handlers can be physically partitioned 
into a separate component from the business logic. For 
example, the data handler could be on a data server 
component near the DB, while the business logic is in 
an application component. 

55 Multiple Data Handlers. Different strategies can be imple- 
mented based upon specific requirements. For example, 
on the client we can use serialization to communicate 
with the server; whereas the server can use standard DB 
access to communicate with DB. 

60 Support for Testing. Similarly, during testing, hard-coded 
data handlers can be created to return dummy data. 
These can then be replaced at run-time or later in 
testing without impacting the code. 
The following information focuses on the implementation 

65 of the Data Handler pattern (Ti Mapper) and the separation 
of the business domain objects from the data retrieval 
mechanism used on the project. 
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FIG. 162 illustrates the TiPersistenceStream 16200 and 
TiMapper 16202. 

TiPersistenceStream and TiMapper 

Within the Rapid Batch Persist Service, objects save and 
load themselves by writing to or reading from a Persistence 
Stream. This is undertaken via the base class (UPersist) with 
specialized streaming code created via the Creation Code 
Generator. As a result domain objects are only "aware" of 
how to stream themselves, and not how the data storage 
mechanism works. 

The first attribute an object writes to the stream is its 
CLASS_ID. The stream then expects the other attributes to 
be put to the stream in the order defined by the mapper class 
(the data handler). This relationship between data handler 
and domain object is controlled via a row class, which 
defines the attributes in the same order as they appear on the 
DB (this class is also created via the Code Generator). 

When the end of the stream is reached, the mapper class 
iterates over the list of attributes within the row and saves 
them via embedded Pro*C. When loading the reverse 
happens, in that, the mapper loads the information from 
Oracle and then populates a row based upon the CLASS_ID 
pulled from the database. 
TiMapper 

A Mapper for a class contains the columns(s) and table 
that the class will be written to, the type of the data and the 
order that they will be read from/written to the stream. It also 
reads and writes rows of data from the database. It generates 
a where clause from the primary key information (PID). A 
database runtime context is obtained from the Transaction 
Service (using the current implicit transaction context). It 
also contains the code to query for sequence ids, for classes 
that use optimistic locking. 

The mapper contains the data retrieval mechanism that 
interacts with the Oracle database instance. As a result, if a 
different technology is used to interact with Oracle (e.g. 
stored procedures, embedded Pro*C, Method/3 Pro*C) only 
the mapper class needs to change. 
TiRow 

A row contains the data to be written to a database row 
from a stream or to be written to a stream from a database 
row. It knows the column names on the table and knows the 
order in which they are read from streams. 
TiMapperManager 

The mapper manager is responsible for creating mappers 
for a given CLASS__ID. Each type of mapper registers with 
the mapper factory when the shared object is loaded into 
memory (using the dynamic registration factory pattern). 
The mapper factory is a singleton read only object. 

The Factory pattern can be used to create the appropriate 
Data Handler for a specific business object. This pattern 
enables the data access method to be changed at runtime 
(e.g. batch mode, online mode or Request Batcher). 

The Stream-Based Communication pattern can be used to 
stream the business object's data to the handler. The stream 
can then be either forwarded to a Request Batcher or can 
parsed and sent to database. 
Individual Persistence 

FIG. 163 illustrates a flowchart for a method 16300 for 
organizing data access among a plurality of business entities. 
Data about a user is retrieved and packaged into a cross- 
functional data object in operation 16302 and 16304. A 
request for data is retrieved from one of a plurality of 
business objects in operation 16306. In operation 16308, the 
business object are directed to the data object such that the 
business object retrieves the entire data object. The business 
object also selects the data from the data object. 
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Both locking and integrity may use a uniform mechanism. 
The business object may retrieve account, customer, and 
bill-related data from the data object. Also, the business 
objects may be able to update themselves independently of 
each other. 

Optionally, new business objects may take advantage of 
existing data access routines. Also, each business object may 
use a uniform access architecture. 

Create a data access architecture that supports reusable, 
independent business objects in the context of atomic, 
functionally-specific transactions. 

A business unit of work, or business transaction, typically 
acts on multiple business entities. But for each individual 
entity, the transaction might only display and update a few 
data attributes. 

For example, accepting bill payment over the phone 
might use the account number, customer name, amount due, 
date due, and credit card number. The transaction could 
therefore avoid accessing many attributes of the account, 
customer, or monthly bill entities. This might naturally lead 
to a data architecture which only fetches required attributes, 
based on the transaction's needs. 

Indeed, a traditional client/server program retrieves data 
in a piecemeal fashion. In this case, the example program 
would typically allocate a single record to fetch and store the 
required data items. Then, an "accept bill payment" data 
access module would fill this structure. This couples data 
access to processing function. 

FIG. 164 illustrates retrieving data piecemeal. 

This traditional style of data access may seem flexible. 
After all, developers can grab whatever data they need for a 
particular business transaction. 

But such access is very unstructured. Different pieces of 
a cohesive account entity, for example, scatter across mul- 
tiple windows. Some windows will use the account's effec- 
tive date; others will not. 

This also introduces redundancy. Retrieving the date 
requires determining the correct database, table, column, 
and type declaration. Yet another developer who needs this 
date, for a different data set, duplicates the effort. This does 
not encapsulate changes, thereby raising costs for testing, 
maintenance, and extension. 

Moreover, each transaction must hand-craft its own 
retrieval procedure. Creating the thousandth new business 
transaction would require creating a thousandth new access 
module. Yet all data items would already have been retrieved 
by other modules. This style of data access is not reusable. 

Finally, business entities are typically less likely to change 
than the transactions, or processes, which act on those 
entities. For example, an enterprise might re -engineer its 
billing function. Regardless of the resulting process, the 
account, customer, and monthly bill objects would likely 
remain. This suggests that transaction-based data access is 
brittle. 

Therefore, data access should be organized around busi- 
ness entities, rather than transactions. Individual Persistence 
packages data into cross-functional objects, rather than 
transaction-specific data structures. Each individual busi- 
ness object, instead of the window or application, manages 
the retrieval of its data items. 

A business object provides public methods for accessing, 
comparing, displaying, and setting that data. Developers can 
therefore no longer plunder the persistent store, selecting 
data items at will. Instead, they must access their data 
through encapsulated, self-requesting business objects. 

With this architecture, the example billing function 
retrieves account, customer, monthly bill, and bill payment 
objects. 
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FIG. 165 illustrates the manner in which the present 
invention retrieves whole objects 16500. 

For reuse, business objects should be able to request and 
update themselves independently of each other. Separating 
the data access for customer and account objects supports 5 
reusing them in isolation. Objects should therefore avoid 
explicitly requesting other linked objects, unless a formal 
containment relationship exists. 

Finally, separation of concern allows business objects to 
remain blissfully unaware of the transactions which use JQ 
them. A business object will not know which data items or 
services it may need to provide to its clients. Thus, the object 
must bring back all its data. 
Benefits 

Reuse. New transactions can take advantage of existing 
data access routines. For example, introducing a new 
business transaction, like perform credit check, would 
use existing customer and account objects. Yet, these 
domain model objects would already know how to 
update themselves. Therefore, the new application 2Q 
would build no new data access code. 

Maintainability and extensibility. This approach supports 
"fix in one place." Any changes to particular data 
elements only need to be changed, tested, and recom- 
piled in one access module, that of the owning business 25 
object. 

Uniformity. Both optimistic locking and referential integ- 
rity (RI) are typically defined at the business object 
level. For example, separate account and customer 
objects typically have their own locking attributes. In 30 
addition, an RI rule usually relates one entity to 
another, such as "all accounts must have a customer." 
Organizing data access around business entities sim- 
plifies locking and integrity. Both can use a uniform 
mechanism, implying that the architecture can hide 35 
technical details. This avoids the hard-coding typical of 
the transaction-based approach. 

Flexibility. Whole object retrieval is extensible. It allows 
a transaction to ask an object for any data. This supports 
maintenance and extension. A developer can easily 40 
change the particular data items a transaction uses. But 
whole retrieval still guarantees that those items will 
already have been retrieved. For example, a future 
release of the accept bill payment window could also 
display the social security number. Yet the data access 4 5 
routines would need no modification. 

Each typical business class will support the standard 
CRUD flag capabilities, of: 

Create 

Retrieve 50 

Update 

Delete 

This access architecture is uniform across business enti- 
ties. The architecture can therefore standardize much of the 5S 
processing. For instance, the architecture can handle, across 
business objects: dirty checks, CRUD flag management, 
optimistic locking, referential integrity, security checking, 
commit scope, request formatting, object streaming/ 
unstreaming, message compression, and error handling. 
Moreover, business entities should support these capabilities 60 
through a consistent, polymorphic interface. 

For example, all business objects could respond to the 
save Data message, to persist any changes, save Data could 
first check, privately, if the object was even modified. Then, 
using private CRUD flags, it could determine whether a save 65 
translates into an insert, update, or delete. Finally, saveData 
could stream out the business object's attributes, based on a 
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defined layout. Then, a transaction persists its business 
objects by simply iterating over the collection, sending each 
member saveData. 

The architecture should also encapsulate the data access 
protocols or products. For example, whether the business 
objects use a relational or object DBMS should be trans- 
parent to calling programs. This minimizes the impact of 
changes to the storage technology. 

Individual Persistence naturally leads to multiple, small- 
grained request messages per transaction. Request Batcher 
solves performance problems with multiple network mes- 
sages. 

Data Handler encapsulates data access code from business 
objects. This protects business logic from changes in data 
access protocols and products. 

Request Sorter handles referential integrity and deadlock 
avoidance in a uniform manner. 
Multi-Object Fetch 

FIG. 166 illustrates a flowchart for a method 16600 for 
retrieving multiple business objects across a network in one 
access operation. In operation 16602, a business object and 
a plurality of remaining objects are provided on a persistent 
store. Upon receiving a request for the business object in 
operation 16604, it is established which of the remaining 
objects are related to the business object in operation 16606. 
The related objects and the business object are retrieved 
from the persistent store in one operation and it is deter- 
mined how the retrieved related objects relate to the business 
object and each other (see operations 16608 and 16610. A 
graph of relationships of the business and related objects is 
instantiated in memory in operation 16612. 

An object navigation pattern of accessing the business 
object and then accessing relationships with the related 
objects may be used to retrieve the related objects. The 
relationships between the business and related objects for 
instantiating the graph of relationships may also be deter- 
mined from a source object, a set of target objects, and the 
name of the relationship. Additionally, the establishment of 
which of the remaining objects are related to the business 
object and the determination of how the retrieved related 
objects relate to the business object and each other may be 
pre-processed before retrieving the selected related objects 
and the business object from the persistent store. 

As an option, a portion of the objects may also be 
retrieved from a cache. Also, as another option, a batch 
request may be sent to the persistent store for retrieving the 
remainder of the objects. 

It is not unusual to retrieve multiple business objects 
within a unit of work. How can the persistent objects 
involved in a unit of work be efficiently retrieved? 

A given business object maintains associations to several 
other business objects. A given unit of work needs to access 
a subset of the defined associations. In order to perform the 
unit of work, the business object and the required subset of 
associated objects must be retrieved from persistent store. 

In the course of performing a unit of work, a set of related 
objects needs to be accessed. Typically, one starts from a 
"root" object and "navigates" relationships to access related 
objects. This process can be repeated on the related objects. 

An entire graph of related objects can be accessed in this 
manner. A natural way to retrieve these objects is through 
lazy instantiation, i.e., objects are retrieved from persistent 
store as each relationship is traversed. This retrieval pattern 
typically requires multiple database/network accesses and 
can have serious performance implications, especially over 
a WAN. 

Therefore, a mechanism is needed to perform the retrieval 
from persistent store in one access operation. This mecha- 
nism includes: 

Support for a declarative multi-object fetch statement 
which defines what is going to be fetched. This multi- 
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object fetch statement does two things. It declares what 
is going to be fetched. It also declares how the objects 
that are being fetched relate to each other. 

Retrieval of the persistent data corresponding to the 
multi-object fetch statement. 

Instantiation of the graph of related objects in memory. 
Benefits 

Performance. Performance is increased by making a 
single trip across the network and a single database 
access to fetch several instances of objects that partici- 
pate in a transaction. The savings can be especially 
noticeable over a. high-latency WAN. 

Continuity. Within the application code, the object navi- 
gation pattern of accessing an object and then accessing 
relationships from that object can still be used to access 
objects. 

Complexity. Requires more elaborate architecture than 
lazy instantiation. 

FIG. 167 illustrates an example of an implementation of 
the Multi-Fetch Object 16700. 

FIG. 168 illustrates the Fetching of a Household object 
16800 along with the other related objects using the multi 
object fetch results. 

FIG. 169 is an interaction diagram showing when the 
multi object fetch is not used. 

Note that if there is a large household, and each hobbyist 
in the household has lots of hobbies and interests, several 
trips to the server will be made to fulfill this query. There 
needs to be a multi-object fetch specification that keeps 
enough detail to know what needs to be fetched and how the 
fetched object will relate to each other. Here is a structure 
that will capture that information. 



struct MultiObjectFetchSpec 
{ 

AxysClassId classld; 
chai **associationName; 

}; 



This is a declaration of the multi object fetch using the 
example above with the Household, Hobbyist, Hobby and 
Interst. 
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There is a class MultiObjectFetch that performs the fetch 
and associates all of the related objects that have been 
fetched so that when these related objects are accessed there 
is no further access to the database. The MultiObjectFetch 
5 class uses the MultiObjectFetchSpec to determine how the 
objects fetched relate to each other. This implementation 
assumes that the persistent framework being used can fill in 
the relationship given a source object, a set of target objects 
and the name of the relationship. 

10 



class MultiObjectFetch 
{ 

public: 

MultiObjectFetch * MultiObjectFetch( 

MultiObjectFetchSpec *mofSpec); 
PersistentObject *fetch( ); 
RWOrdered *fetchRows( ); 

}; 



20 There is an assumption that the Household, Hobbyist, 
Hobby and Interest business objects inherits from a common 
base class, PersistentObject. If the restriction on the house- 
hold is to bring back one Household, fetch( ) would used. If 
the restriction on the Household will bring more than one 

25 Household, fetchRows( ) would be used. The fetch and the 
fetchRows brings back the Household objects(s) and the 
related Hobbyists, Hobbies and Interests. 
Static Approach (using Stored Procedures) 

A stored procedure would be written that would retrieve 

30 the Household object(s), Hobbyist objects related to the 
Household objects, Hobby objects related to the Hobbyist 
objects and the Interest objects also related to the Hobbyist 
objects. It is important that the stored procedure fetch the 
objects in this order since the multi object fetch spec 

35 declared that this is the expected order. These fetched 
objects would then be passed to the MultiObjectFetch object 
which would fill in all the relationships of the returned object 
using the fetch specification. 

Dynamic Approach (Dependent Requests/Pending Actions) 
40 The multi-object fetch can be pre-processed before send- 
ing the request to the database. Any objects that can be 
fetched from the cache will be fetched from the cache. The 
remaining requests that cannot be satisfied from the cache 
will then be sent as a batch request to the database. This 



const HOUSEHOLD_CLASSID = 1; 
const HOBBYIST_CLASSID - 2; 
const HOBBY_CLASSID = 3; 
const INTEREST__CLASSID - 4; 

const NUMBER_OF_HOUSEHOLD_RELATIONSHIPS - 1; 
const NUMBER_OF_INDIVIDAUAL__RELATIONSH[PS - 2; 
static char *EmptyRelationship[l] = { 0 } ; 
static char * 

HouseholdRelationships[NUMBER_OF_HOUSEHOLD_RELATIONSHIPS 
+ 1] - {"Hobbyists", 0}; 
static char * 

HobbyistRelatior^hips[WMBER_OF_INDIVlDAUAl^RriLAnONSHrPS 

+ 1] = {"Hobbies", "Interests", 0}; 

static MultiObjectFetchSpec HobbyInterestMofSpec[5] - 

{ 

{ HOUSEHOLD_CLASSID, Household Relationships }, 
{ HOBBYIST_CLASSID, Hobby istRelations hips }, 
{ HOBBY_CLASSID, Empty Relationship }, 
{ INTEREST_C1j\SSID, EmptyRelationship }, 
{0,0} 

}; 
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requires complex processing to determine if the cache can be entire associated object In addition, since these object iden- 

used. This dynamic processing assumes that dynamic SQL tifiers uniquely identify an object instance, they can be 

will be used since it is not known at design time what objects used/passed in place of memory pointers. When the object is 

will be found in the cache and what objects still need to be needed, simply restore the instance using the object identi- 

fetched from the database. 5 fier. 

Dependent Request — used in dynamic approach Benefits 

Request Batcher — used in dynamic approach Performance. Objects are retrieved only when they are 

Batching Update — similar to bathing of fetches but used needed. 

to batch updates Caching and identity management. Object Identifiers can 

Relationship Stereotype— The setAssociation method is 10 be used to provide the unique id needed to implement 

called to fill in the relationships ™ d i< l enU / ty management. 

Object Identifiers as Objects ^ ob J ect identifier (or OID) must contain enough infor- 

FIG. 170 illustrates a flowchart for a method 17000 for mat £V t0 ^uely identify the instance Tins identifier 

implementing an association of business objects without could be a unique row id generated by a database a UUID 

retrieving the business objects from a database on which the 15 S enerated \ a ^ or a unique stnng generated from one 

business objects are stored In operations 17002 and 17004, °f more a »" b f utes ' " 1S generally desjrable to have a different 

a business object is provided and an instance of an associ- class of ° ID for each °* ° b J? Ct ; th( * eby C ™ l * g t *™? 

ated object is stored on a database. An association of the environment. It should also be noted that OID s 

business object with the instance of the associated object is should have value semantics. 

, . . , . i taaj£ t rt _ f - n AA fi _ nn In addition, a mechanism must be available to retrieve 

determined in operation 17006. In operation 17U08, an 20 , . . ' _ T _^ __. , . 4 . , 

• . . .j • .j * • ■ c ** -~„u*a obiects eiven their OID. This can be as simple as a static (or 

object identifier is generated contaming information includ- ^vvw ^ ^ f v 

• .t. j . • l* i_ ■ * class) method such as eetByld that takes the OID as an 

mg the determination association which is necessary to J , • * r ^ u- * a 

retrieve the instance of the associated object from the ^ ™? returns the instance of the object. A more 

database. The object identifier is loaded when the business sophisticated approach would be to implement this and other 

*• nnm a i *• ** iu~ ~ persistence related methods in a generalized utility class. 

obiect starts in operation 17010. A location of the instance 25 £, , . , , . t ..f t t . , ; ... 

» . _i « • , , . , j * • j * Below is a simple example that illustrates the relationship 

of the associated object on the database is determined in ™ a ~» v f f 

operation 17012 from the object identifier and the instance b ,f. tween tw ° c,asses usm S ° b J ect ^nt.fiers. Please note that 

of the associated object is retrieved from the database in ™ m V le r » an ° xtreme simphficataon^A useful imple- 

o eration 17014 mentation of this pattern would exist as part ot a persistence 

^object identifier may be used to provide a unique 30 framework that would include many additional methods and 

identity that is required for implementing caching and a strac 10ns - 
identity management. Also, the object identifier may include 
a unique row identifier generated by the database, an iden- 

tifier generated by a utility, and/or a unique string generated c i ass Fooid 

from one or more attributes. As an option, different types of 35 public: 

business objects may be provided. In such a case, a different . " accessor*, constructors and destructors 

class of object identifier may be generated for each type of PnVa iong_id, 

business object. As another option, the determination of a j. 

location of the instance and the retrieval of the instance of class Foo 

the associated object may also include the taking the object 40 { 

identifier as an argument and returning the instance of the PUbh ^ aC cesso r s, constructors and destructors 

associated object. static Foo* getById(FooId& id); 

Most useful business objects have a relationship, or }; 

association, with other business objects. How should this class Bar 

association be implemented without having to read the 45 p Ublic . 

associated object's state from the database? Foo* getFooQ 

Most useful business objects have a relationship, or { 

association, with another business object instance. return Foo::getByid(Foo[d); 

m . . . . it i i_- ■ j • * // The caller now owns the instance of Foo. Use of an 

Traditionally, this relationship is expressed as a pointer or „ auto ptr here fa highly recommended . 

reference to the object. However, pointers (and references) 50 } 

are memory constructs valid only so long as the object state private: 

exists in memory. When storing the object to a persistent Fooid_fooid; 

storage medium (such as a relational database) these asso- *' 

ciations need to be expressed in some other way. Likewise, 

when the object is restored from persistent storage, the 55 Collaborations 

associations need to be reinitialized since it is unlikely that Identity Manager — Uses Object Identifiers as unique 

the associated object will reside in the same memory loca- key's for storing persistent state objects. 

tion. If the associated object is stored in the persistent Persistent State Separate from Persistent Object — Uses 

medium, this usually involves restoring it as well. This can Object Identifiers embedded in persistent state objects to 

become a long and expensive process if the association 60 eliminate coupling. 

graph corresponding to the restored object is large or com- Object Identity Cache 

plex. It is particularly undesirable if the associations are not FIG. 171 illustrates a flowchart for a method 17100 for 

even traversed by the application. mapping of retrieved data into objects. An object is retrieved 

Therefore, implement the associations using object iden- from a data store and cached in operations 17102 and 17104. 

tifiers that contain the necessary information to retrieve the 65 A unique object identifier is assigned to the object in 

object if it is needed. These objects can then be loaded when operation 17106. The object identifier is mapped to a rep - 

the object is restored, eliminating the need to restore the resentation of the object in a dictionary in operation 17108. 
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When a request for a reference to the object is received in 
operation 17110, the object identifier of the object is 
retrieved from the dictionary in operation 17112. The 
requested reference is associated with the representation of 
the object stored in the dictionary in operation 17114. 5 

In one embodiment, a data store may be accessed if the 
object identifier is not found in the dictionary to retrieve the 
object so that the process may be repeated with the retrieved 
object. In another embodiment, a query may be performed to 
retrieve multiple objects. A check may be performed to 10 
verify that each object is already cached so that objects not 
already cached may be cached. 

Also, if an object in the cache has changed since read, an 
error may be raised if the object retrieved has changed since 
read and the object retrieved may be ignored if the object 35 
retrieved has not changed since read. If an object in the 
cache has not changed since read, the object in the cache 
may also be replaced with the object retrieved if the object 
retrieved has changed since read and the object retrieved 
may be ignored if the object retrieved has not changed since 2 q 
read. Further, if a query is guaranteed to return at most a 
single object, the cache may be used prior to going to the 
data store by sequentially applying the function to each 
object in the cache and implementing a predicate function 
which answers whether or not a given object satisfies the 2 s 
query. 

Within a client context (e.g., a logical unit of work), the 
same object may be referenced more than once. How can 
object identity be preserved and redundant accesses to 
persistent store be avoided? 30 

(Although this pattern is not specific to relational 
databases, we will, for the sake of concreteness and clarity, 
describe the pattern in terms of an object-to-relational 
mapping.) 

Objects can be stored in and retrieved from a relational 35 
database. A retrieval strategy that simply translates relational 
data into objects in memory will almost certainly result in 
the instantiation of multiple copies of the same object. 
Furthermore, such a strategy is inefficient as the same data 
may be repeatedly and unnecessarily read from the database. 40 
This violates object identity and contributes to performance 
problems. 

Suppose the class Account has an association with the 
class Customer. Suppose the instance of Account ABC is 
associated with the instance of Customer 123. The following 45 
demonstrates multiple requests to Customer 123. 

Example 

customerl23=getCustomer(123) 

accountABC=getAccount(ABC) 50 
secondRefererenceToCustomerl23 = 

accountABC.getCustomer( ) 
Note that customerl23 and secondRefererenceToCus- 
tomerl23 are the same customer. In this scenario, the desired 
behavior is to have the data store accessed once for cus- 55 
tomerl23. Also there should only be one instance of cus- 
tomerl23 in memory, customer 123 and secondReferenc- 
eToCustomer 123 should reference this instance of the 
customerl23. 

Therefore, the mapping of retrieved data into objects 60 
should be mediated by an Identity Cache. FIG. 172 illus- 
trates an Object Identity Cache. 

Logically, an Identity Cache is a dictionary which, for 
each cached object, maps a unique object identifier to a 
representation of the object. Each object must be assigned an 65 
object identifier (OID) which uniquely identifies the object 
over the life of the system. 



The mediation mechanism works as follows: When a 
reference to an object is requested, the identity cache is 
consulted. If the object's OID is found in the cache, the 
requested reference is associated with the representation of 
the object stored in the cache. If the OID is not found in the 
cache, the data store is accessed. The object representation 
that is retrieved from the data store is inserted into the cache 
and the requested reference is associated with it. 
Benefits 

Performance. Performance is improved for frequently 
accessed objects since they are only fetched from the 
database once. 
Identity Preserved. Object identity is preserved since 

objects are cached based on the objects OID. 
A dictionary can be used to implement the Object Identity 
Cache. The following points should be considering when 
implementing an Object Identify Cache. 

A query could be performed that returns multiple objects. 
Each object that is retrieved must be checked to see if it is 
already in the cache. If it is not in the cache it must be 
inserted. The following shows what should be done when an 
object is retrieved that is already in the cache to get is 
correctly inserted into the cache. 



Object retrieved has 
changed since read 



Object retrieved has 
not changed since read 



Object in cache has 
changed since read 



Objea in cache has not 
changed since read 



Raise an error. At 
commit transaction 
there will be an 
optimistic lock failure 
so it is better to raise 
it now. 

Replace the object in 
cache with the object 
retrieved since the 
retrieved object is 
newer. 



Ignore the 
retrieved object, 
the object in cache 
is newer and the 
changes should not 
be lost. 
Ignore the 
retrieved object, it 
is already in the 
cache. 



If the object is not in the cache when the object is 
retrieved, a simple insertion into the cache can be done. 

If a query is guaranteed to return at most a single object, 
the cache may be used prior to going to the database by: 
implementing (for a given class) a predicate function 
which answers whether or not a given object satisfies 
the query 

sequentially applying the function to each object in the 
cache. 

A multiple row query must go to the database unless there 
is a mechanism to indicate that the class is completely 
cached. This is applicable to static reference data. 

Life Time of cached objects can affect Cache size. If life 
time of the cache is associated with a transaction there will 
be no problem. If the life time of the cache is associated with 
a longer lived entity such as a thread or a process, removal 
of objects from the cache must be actively managed. Two 
commonly used strategies are reference counting and LRU 
purging. 

Collaborates with 

Object Relational Query pattern describes a mechanism 

for storing objects in a relation database. 
Object Identity 

Persistent State Separate from Persistent Object 
Used by 

Context Management 

Each Context (e.g., transaction, thread, etc.) owns an 
Identity cache which holds all of the objects in that context. 
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Persistent State Separate from Persistant Object 

FIG. 173 illustrates a flowchart for a method 17300 for 
separating logic and data access concerns during develop- 
ment of a persistent object for insulating development of 
business logic from development of data access routine. A 5 
persistent object being developed is accessed and a state of 
the persistent object is detached into a separate state class in 
operations 17302 and 17304. The state class serves as a 
contract between a logic development team and a data 
access development team. Logic development is limited by 1Q 
the logic development team to developing business logic in 
operation 17306. In operation 17308, data access develop- 
ment is restricted by the data access development team to 
providing data creation, retrieval, updating, and deletion 
capabilities. 15 

The business logic team may develop persistent objects 
that manipulate the state of the persistent object in accor- 
dance with business requirements. In one embodiment, the 
state may be implemented as a structure of values of basic 
data types. In another embodiment, the state class may 2Q 
contain member variables of lower data types including 
basic data types, extended basic data types with value 
semantics, other state classes, and/or vectors of the basic 
data types, the extended basic data types with value seman- 
tics and other state classes. 

Optionally, the state class may support data structures of 
arbitrary shapes. Supporting classes may manipulate the 
state in a polymorphic fashion. As another option, the state 
may be further implemented as a class that contains key- 
value attribute pairs. The state class may also contain a 3Q 
keyed data structure containing attribute names and attribute 
values. Additionally, the state can also be asked to write data 
to a stream. 

When designing and implementing persistent objects, 
how do we effectively insulate the development of business 35 
logic from the development of database access routine? 

Given the use of a relational database as the persistent 
store, the scope of a persistence architecture can range 
across the following levels of transparency and automation: 
Heavyweight, fully-automated persistence architecture. 40 
Including the mapping of the object model to the 
database schema and generation of all the database 
access code 

Variants of the above scheme allowing the customization 

of database access code 45 
Lightweight mechanism which provides generic persis- 
tence capabilities to business objects but delegates all 
database access to separately developed data access 
routines. In this case, the data access routines are not 
part of the persistence architecture per se. 50 
Minimal persistence approach in which each business 

object is directly responsible for database access 
From a persistence perspective, no matter which of these 
approaches is used, development of the system and archi- 
tecture presents two distinct challenges to the development 55 
team. The first challenge is to accurately represent the 
business logic as a collection of business objects that include 
interfaces for performing the correct set of functionality. The 
second challenge is to be able to create, retrieve, update and 
delete (CRUD) records that represent the state of these 60 
business objects from the database in an efficient fashion. 

Data access and business logic are significantly different 
tasks both in their goals and development approaches. 
Consequently, except when a fully automated persistence 
architecture is used, it is often the case that two separate 65 
teams are responsible for the development of business logic 
and data access. If both teams work directly with the 



business objects, serious contention may result. Problems 

encountered in practice include: 

Changes to business logic that impacts the development 
(e.g., requires recompilation) of database access code 
even when there is no change to the attributes of 
business objects, (Note: recompilation can be a prob- 
lem even if a fully automated persistence framework is 
used.) 

Changes to the database schema can impact the develop- 
ment of business objects 

The data access team may unduly influence the design of 
the business objects, leading to a data-centric model 
and design 

The two teams* development schedules need to be in 
sync; slippage on one team can adversely impact the 
other team's progress 

Therefore, detach the state of the business object into a 
separate state class that can be agreed upon and completed 
prior to the start of significant development by either the data 
access team or the business object team. This class should be 
nothing more than the raw data (preferably basic data types) 
used to represent the state of the object. The business object 
contains all business logic and a reference/pointer to an 
instance of the respective state class. This allows the devel- 
opment of business logic and data access to proceed in 
parallel with the state class serving as a contract between the 
two teams. 

Using this approach, it is important to limit data access 
focus to providing CRUD operations (i.e., no business logic 
provided by stored procedures). The purpose of the data 
access portion of the application is to provide essential 
access to the data used by the business objets, and deliver 
this data in the most efficient way possible. Likewise, the 
purpose of the business object team is to develop business 
objects that manipulate the state of the object in accordance 
with the business requirements. Maintaining this separation 
insures there is no overlap between the development teams. 
Benefits 

Development Time. Data access and business logic can be 
developed in parallel reducing overall development 
time. 

Separation of concern. Data access remains separate from 
business logic, improving the understandability of the 
design. 

Testability. Business objects can be more easily devel- 
oped and tested based on data access stubs, thereby 
relieving the business object development teams from 
dependencies on the data access classes and the data- 
base libraries. 

Caching and identity management. Separating the persis- 
tent state from the persistent object can be leveraged to 
aid in managing multiple class instances that represent 
the same entity (see the Object Identity Cache pattern). 

Object distribution. Separating the persistent state from 
the persistent object can aid in passing state in a 
distributed system. In cases where in is necessary to 
pass an object as an argument to a distributed method, 
it is more desirable from a performance perspective to 
pass the object's state as opposed to a remote reference. 
A new instance can then be created from the state, 
manipulated locally and then returned to the caller. 
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The persistent state can be implemented in a variety of 
ways depending on the requirements of the system. They can 
roughly be described by the following 
Implement the State as a Structure of Values of Basic Data 
Types 

Each business object class has an associated struct. This 
is the most straightforward approach, although also the least 
flexible. With this approach, the business logic may need to 
manipulate lower level data types contained in the state 
object. 

Supporting classes which need to manipulate the state 
object (in order to retrieve data from the database or pass the 
value between processes) need to be knowledgeable about 
the struct data type to manipulate it. In addition, copying the 
struct may be non-trivial if it contains dynamically allocated 
memory. 



struct State_Data 
{ 

long id; 
char code[8]; 
string value; 

}; 



Implement the State as a Class Containing Member Vari- 
ables of Basic Data Types 

1. Implementation using a "developer-friendly" state class: 
A state class can contain basic data types (except char*), 
extended basic data types with value semantics (e.g., 
currency, String), other state classes, and vectors (not 
arrays) of all of the above. This does not, however, imply 
that the class is a flexible (dictionary-like) data structure. 
These state classes could/should all inherit from a com- 
mon abstract base class which defines (but does not 
implement, at least in C++) a serialization protocol (Java 
is a different story than C++ because everything is seri- 
alizable almost by default). 



class StateClass 
public: 

virtual void read(Stream inStream) = 0; 
virtual void write(Stream outStream) = 0; 

}; 

class State Data : public StateClass 

{ 

public: 

virtual void read(Stream inStream); 

//implementation reads state data from stream, 
virtual void write(Stream outStream); 

//implementation writes state data to stream. 

Private: 

long id; 
char code[8]; 
string value; 

}; 



2. Implementation using an enhanced kind of the class 
described in (A) but which also happens to be a flexible 
data structure (in the sense that the same class can, similar 
to a dictionary, support data structures of arbitrary 
shapes). 

This approach provides more flexibility since some com- 
mon behavior can be abstracted into a base class. In 
addition, supporting classes which need to manipulate 
the state object (in order to retrieve data from the 
database or pass the value between processes) can do so 
in a polymorphic fashion. Also, copy constructors and 
destructors can be used to handle dynamically allocated 
memory. 
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Implement the state as a class that contains key-value 
attribute pairs. 

This is an alternative approach to the one listed above. 
Using this technique the state class would contain a keyed 

5 data structure (e.g. a dictionary) containing keys (the 
attribute name) and values (the attribute value). In cases 
where you want to copy the state or pass it to another 
process, the supporting code does not need to know the type 
of the state object it is working with. State objects can 

10 simply be asked to read or write their data to and from a 
stream or string. While this offers a more dynamic solution, 
it should be noted that with this solution additional logic 
would need to be included in the persistent object to insure 
the validity of the associated state class. 

is In all of these approaches, another important concept is 
the implementation of associations between objects. In 
general, the best approach is to store these as Soft Refer- 
ences to the other objects as opposed to actual pointers. This 
illuminates the need to load a large graph of objects when 

20 only one is needed, as well as easing the question of whether 
to implement a deep or shallow copy. 

Identity Manager: Manages a collection of persistent state 
objects for a given class. 

Context Manager: Used in conjunction with Identity 

25 Manager to maintain separate collections of persistent state 
objects for separate application contexts. 

Lazy Instantiation: Restores persistent state object for a 
given object instance on-demand. 

Object Identity Cache: Caches persistent state objects 

30 referenced by persistent objects. 
Piecemeal Retrieval 

FIG. 174 illustrates a flowchart for a method 17400 for 
providing a warning upon retrieval of objects that are 
incomplete. An object is provided with at least one missing 

35 attribute in operation 17402. Upon receipt of a request from 
an application for the object access to the attributes of the 
object is allowed by the application in operations 17404 and 
17406. A warning is provided upon an attempt to access the 
attribute of the object that is missing in operation 17408. 

40 The warning may include information on how to handle 
the missing attribute. An implicit transaction may also be 
called by the object upon the attempt to access the attribute 
of the object that is missing. In addition, an explicit trans- 
action may be called by the object upon the attempt to access 

45 the attribute of the object that is missing. Also, the transac- 
tion may also include finding the attribute that is missing. 

When legacy transactions don't allow object or entity 
based retrieval, how do we retrieve useful objects? 

Object and component based projects designed and built 

50 from the ground up will likely have a well thought out 
component model and architecture where GUI widgets are 
linked or bound to domain objects. Data access (and 
retrieval) for these objects is organized around the business 
entity, rather than a transaction, and so data is packaged into 

55 cross-functional objects, rather than transaction -specific 
data structures. Each business object manages the retrieval 
of its data items. 

These domain objects provide public methods for 
accessing, comparing, displaying, and mutating data. 

60 Therefore, developers will only access data through these 
encapsulated, self -requesting domain objects. (See Indi- 
vidual Persistence). 

For example a billing application that accepts bill pay- 
ment over the phone might use the account number, cus- 

65 tomer name, amount due, date due, and credit card number. 
With an Entity-Based Data Access architecture, the account 
17500, customer 17502, monthly bill 17504, and bill pay- 
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meat objects 17506 will all be retrieved. FIG. 175 illustrates 
an Entity-Based Data Access System. 

This architecture is preferred if conditions allow, however 
legacy programs usually retrieve data through transaction or 
message based systems. These transactions often have two 5 
notable characteristics. One, a business unit of work or 
business transaction often acts on multiple business entities, 
and two, for each individual entity, the transaction might 
only retrieve and update a few data attributes. 

Using the same bill payment example, a legacy system 1Q 
might utilize a 'accept bill payment' transaction. This trans- 
action would require only a small portion of the attributes for 
the account, customer, or monthly bill entities and so the 
data would be retrieved piecemeal only as required by the 
transaction. 

FIG. 176 illustrates a Retrieving Data Piecemeal System. 15 

In this case, the transaction would allocate a single record 
(an 'accountPaymentData' 17600 structure as shown in the 
Figure) to fetch and store the required data items. This 
structure would then be used to populate the business 
entities. 20 

As a result, domain objects are left incomplete and 
therefore unsuitable for use by all services. This forces the 
developers of services to know and understand the use of 
transactions to retrieve objects. 

Therefore, when legacy circumstances dictate, retrieve 2 s 
data piecemeal, on a transaction basis as necessary rather 
than as complete business entities and develop mechanisms 
to handle access and updates to missing attributes of piece- 
meal objects. 

By default, objects should return a warning when a 30 
missing attribute is accessed with no other means to retrieve 
it. This warning would simply let calling applications know 
that an attribute is missing or unavailable. The calling 
application would then have to determine how to handle 
these missing attributes. 35 

Apreferred approach to handling missing attributes would 
be to use multiple overlapping transactions. While, each 
transaction might only populate a part of the object, the 
transactions taken together assemble complete objects. 

This use of overlapping transactions could either be 4 q 
implicit or explicit to the objects. An implicit transaction 
would be called by the object when a missing attribute is 
accessed. This method of lazy retrieval may be preferable 
because it is transparent to the calling application. 

An explicit transaction would be called by a task inde- 45 
pendent of the object. Note however, that explicit transac- 
tions would either require that the task holds the object or 
that an object identity mechanism is used to find the existing 
object rather than create a new one. 

In some cases, new transactions can be created for the 50 
explicit purpose of retrieving full or partial business entities. 
This approach requires a thorough knowledge of the legacy 
system. 

In other cases, the legacy code can be opened and the 
transactions modified to bring back additional data. Care 55 
should used when doing so as legacy code is often fragile 
and poorly documented. 
Benefits 

Legacy Reuse. The overwhelming benefit of piecemeal 
retrieval is that it enables reuse of legacy systems. 60 
Clients generally have a substantial investment in their 
existing systems and they will be hard pressed to 
convert them to component based systems built on 
objects. This pattern allows new systems to reuse 
existing business logic through their transactions. 

Performance and Impedance. Objects based on transac- 
tions typically bring back only that data which is 
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needed. The transaction is typically mapped directly to 
change that the user is trying to make. This improves 
performance by reducing the number of network calls 
and only bringing back data that is needed. 
Individual Persistence organizes data access around busi- 
ness entities rather than transactions. 

Object Streaming handles the conversion of data from the 
structures received from transactions into business objects. 

Transaction Service Patterns (1012) 
Transactions and LUWS 

A transaction is a set of business events that, coupled 
together, accomplish a particular business function, such as 
turning on gas service. Because the events are logically 
related, their data changes are logically related as well. 
Taken together, these data changes create a new, consistent 
state for the business model. 

While a transaction is in process, the state of the business 
model may not be consistent, so it is necessary to manage the 
entire transaction from its point of origin to its point of 
completion. Whether the transaction is successful or not, the 
point of completion will always result in a steady, consistent 
state for the business model. For successful transactions, 
data changes will be committed and the business model will 
reflect all new business data associated with the transaction. 
For failed transactions, data changes will be rolled back and 
the business model will appear as it did prior to the start of 
the transaction. 

To help manage the transaction from point of origin to 
point of completion, each transaction is organized through a 
single Logical Unit of Work (LUW). This LUW manages the 
business model and any of its subsequent data changes. 
While both users and internal exceptions can determine the 
success of a transaction, the LUW handles the commit and 
rollback operations. 

FIG. 177 illustrates a Commit and Rollback routine 
17700. 

As transactions become more complex and require a 
greater scale of changes to the business model, the LUW 
trying to manage these changes becomes large and unwieldy. 
To simplify these transactions, the LUW is broken down into 
nested, more granular, logically related units of work called 
Secondary LUWs. Secondary LUWs are identical to LUWs 
except that their commit and rollback operations affect only 
the business model of their parent LUW and are not per- 
sisted to a data store. Consequently, a secondary LUW must 
manage its data changes differently than its parent. 

FIG. 178 illustrates Nested Logical Units of Work. 

One method for managing changes to the business model 
involves copying the model into the secondary LUW. 
Another often simpler approach is to store both old and new 
(or potential) values for all objects in the business model. 
Transaction Patterns 

In the process of managing its business model, a LUW 
will often have to send messages to all business objects 
within the LUW, Examples of such messages include 
saveData Changes, retrieve, or isDirty. Rather than hardcod- 
ing a call to each object in the model, the pattern LUW 
Context suggests using a bag (or collection) to hold all 
objects referenced by the LUW. Then, a single message can 
be sent to the bag which will forward it to all objects within 
it. 

Support for user multi-tasking can also present problems 
for LUWs. Through multi-tasking, multiple LUWs will be 
running concurrently. Problems occur if the business models 
of these concurrent LUWs overlap and the transactions 
attempt to write to the same business object. A call center 
representative trying to solve two customer problems during 
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the course of one call is one example of this scenario. The The dependent request may not have a primary key. In 

Separate Models pattern helps solve this issue by assigning such situation, the response to the parent request may 

each LUW independent copies of their portion of the busi- include the primary key for allowing the dependent request 

ness model. This keeps one transaction from interfering with to be responded to. As another option, the dependent request 

another. 5 may also include a pointer indicating that the dependent 

There are also several patterns that address problems request is dependent on the parent request. In this situation, 

related to sending transactions across the network. These the pointer may be passed to the parent request during the 

patterns typically focus on minimizing network messaging. ste P of batching the requests into the network message. 

When an LUW is called to commit, the transaction will , Additionally, the pointer may be a configurable field of 

assemble the necessary objects from the business model to 10 iho A *P™*J« request. The requests may also be reused 

send their data changes to the information services layer. independently of each other In event another aspect of the 

rr.- c . .... , . „ j i_- , present invention, the dependent request may wait for the 

This group of objects wil inc ude all new and dirty objects * ^ at (he ^ for min ^ izi / etwork traffic 

as well as any objects marked for deletion. For each business Durifl fetrievalj Qne st depend on the response 

object, the transaction will likely have a corresponding data for another request Nevertheless, ensure that a single 

request. If each of these requests were then sent to infor- is network message contains both requests, while using 

mation services independently, a large number of network Request Batcher. 

messages would result. To solve this problem, the Request A business transaction typically acts on multiple business 

Batcher pattern batches all requests associated with a trans- entities. Consider an account maintenance window, which 

action together into one network message. On the other end edits information from account, customer, credit profile, and 

of the network, Information services would unbatch the 20 home and work addresses. Given a unique account identifier, 

transaction requests and persist the data changes. the business transaction can retrieve all five objects. 

Another problem that may arise when multiple requests Once the account retrieves all of its data, it will know its 

are sent for a given transaction is deadlock. Deadlock occurs unique customer identifier. 

when two requests are trying to lock the same pair of objects. The customer can then retrieve its own data, which 

Each request locks one object and waits to commit until it 25 includes the identifiers for the credit profile and both 

can lock the other. Therefore, each request will wait for the addresses. Finally, the profile and addresses can retrieve 

other to complete while neither is able to do so. The Request their data * In this case > P rofile and address retrieval depends 

Sorter pattern works with Request Batcher to handle this on customer data; customer retrieval in turn depends on 

problem by sorting requests as they are being unbatched by „ u u ; . . 

Information Services. A request is not allowed to proceed 30 „ However ' Persistence requires tha each object 

... j j . ? i.j have its own, independent request module. That is, custom- 

unul any dependent requests are completed. efs Jq nQ{ al F Qeed ac ^ unts tQ be retrieyed ^ a 

During retrieval, one request may depend on the response customer ' s unique identifier has been filled m _ re gardless 

data for another request. For example, a business transaction of by wnom _ it retrieves its data independently, 

that tnes to retrieve a customer when given a customer ID In theorv> mis independence is not an issue. The account 

will probably also want to retrieve the customer's address. 35 cou i d ^ t get i^ data> After the customer's identifier was 

However, the transaction won't have the address ID until the filled, the customer could send its own request, 

customer is retrieve. Thus multiple network messages are In practice, however, sending multiple messages, in series 

required when one request is dependent on another. The like this, degrades network performance. Request Batcher 

Dependent Request pattern solves this problem by allowing 18000 provides a solution which bundles up requests into 

a batched request to indicate that it depends on another 40 one network message, thereby minimizing traffic. FIG. 180 

request. illustrates a Batching Retrievals and Dependency. 

As these patterns demonstrate, there is a high degree of This batching framework applies not only to update 

correlation between Transaction Services and Information messages. For retrieval as well, one overall, batch request 

Services. Many of these transaction patterns require an receives one batch response. Yet an individual batched 

understanding of Information Services patterns. Two such 45 request may depend on the response data from another 

examples are Individual Persistence and Piecemeal batched request. The serial nature of the two requests must 

Retrieval. It is recommended that these patterns be read and be preserved, even while the requests actually go in the same 

understood prior to using Request Batcher, Request Sorter batch, in parallel. 

and Dependent Request. Therefore, additional mechanisms should allow a batched 

Dependent Request 50 request to indicate that it depends on another request. If a 

FIG. 179 illustrates a flowchart for a method 17900 for business object does not have its primary key — or other 

allowing a batched request to indicate that it depends on the attributes guaranteeing a unique match — it becomes a 

response to another request. A group of business objects Dependent Request. Because a dependent cannot fetch itself, 

necessary for a transaction are provided in operation 17902. some other business object will inevitably have the neces- 

Logically-related requests received from the business 55 sary foreign key. The dependent request will therefore 

objects are batched into a single network message in opera- register its dependency on this other object, 

tion 17904. One of the requests is a parent request. Received This object, the parent request, can have multiple depen- 

from the parent request in operation 17906 is a register that dents. The aforementioned customer had credit profile and 

at least one of the requests is dependent upon the response address dependencies. This implies the need for an arbi- 

data. The network message is sent across a network and the 60 trarily large collection of dependent requests; A dependency 

requests are unbundled from the network message in opera- collection can even include requests for multiple instances 

tions 17908 and 17910. Upon receipt of a response to the of the same class. This was the case with two address 

parent request in operation 17912, data is directed from the requests depending on the same customer, 

response to the parent request to the dependent request in FIG. 181 illustrates the Dynamically Setting Dependency, 

operation 17914. Received from the response to the parent 65 Dependencies should not be hard -coded. Any business 

request is a response to the dependent request based on the object can register as dependent on any other object which 

received data in operation 17916. can provide the necessary data. 
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In this manner, dependencies can be set at run-time. This 
could happen while building the model, or as requests 
register with Request Batcher. 
Benefits 

Performance. This solution supports request batching for 

retrieving interdependent models. 
Reuse. Because dependencies are not hard-coded, busi- 
ness objects can be reused independently of each other. 
Loose Coupling. When a request dynamically registers its 
dependency, it need not know anything about its parent 
request. The dependent effectively says, "I don't know 
who you are, but I know that your response data 
contains my identifier." 
Dependent Request would be irrelevant were it not for the 
"transaction impedance mismatch." This mismatch means 
that transactions no longer map one-to-one to access mod- 
ules. Individual Persistence is the approach which dictates 
that each business entity have its own independent access 
module. 

Request Batcher solves the performance problems of 
sending multiple, small-grained request messages over a 
network. But the resultant single message must support 
dependencies, with Dependent Request or a similar mecha- 
nism. 

LUW Context 

FIG. 182 illustrates a flowchart for a method 18200 for 
sending a single message to all objects in a logical unit of 
work. A group of business objects necessary for a transaction 
are provided and managed in a logical unit of work in 
operations 18202 and 18204. A receiver is created which 
communicates with the business objects in the logical unit of 
work in operation 18206. Upon receiving a message for the 
business objects in the logical unit of work in operation 
18208, the message is directed to the receiver in operation 
18210. The receiver also forwards the message to each of the 
business objects in the logical unit of work. 

Several groups of business objects necessary for a trans- 
action may also be provided with each group of business 
objects being managed in a separate logical unit of work. 
Also, a separate receiver may communicate with each group 
of objects. As another option, a request batcher in commu- 
nication with the receiver may also be provided for batching 
requests from the business objects for delivery. In such an 
embodiment, the request batcher intercepts the requests 
from the business objects and holds the requests until told to 
deliver the requests by an activity associated with the logical 
unit of work. 

Optionally, the receiver may hide technical details includ- 
ing details of persistence and garbage collection from busi- 
ness developers. As a further option, the business objects 
may be distributed across a network. Also, the receiver may 
distribute the message to each of the business objects across 
the network. Additionally, the logical unit of work may 
optionally be modeled as an object in software. 

Applications often need to send technical messages, like 
saveDataChanges( ) or release( ), to all business objects in 
an LUW. Do this in a consistent manner and hide technical 
details from business developers. 

Consider an Account Payment window, which displays 
information about an Account, Customer, Monthly Bill, and 
Payment. This window occasionally needs to send generic, 
technical messages to all business objects within its LUW. 
This messaging has nothing to do with the window's 
application-specific behavior. In fact, the other windows in 
the system need to send the same, generic messages to their 
LUW business objects. Although the business objects 
receiving these messages differ from window to window, the 
messages remain the same. 
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In addition, this messaging typically has an arbitrary 
order. All that matters is that all business objects eventually 
receive the same message. 

For example, the window might use Individual Persis- 
tence. Then, when the user decides to save the window, all 
business objects receive a message like saveDataChanges(). 
The resultant pseudo-code would look like: 



AcoountPaymentActivity: :saveDataChanges( ) 
{ 

//Propagate along the save message to all business 
//objects in my LUW. 
this.getAccount( ).saveDataChanges( ); 
this.getCustomer( ).saveDataChanges( ); 
this. getMont hi y Bill ( ).saveDataChanges( ); 
this. gctBUl Pay ment( ).saveDataChangcs( ); 
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} 



A retrieveData( ) message might also be required, if the 
object model pre-instantiates objects before retrieving them. 
Similarly, refresh( ) could be used: the business object, if 
dirty, replaces any changes with data originally from the data 
store. 

Even without Individual Persistence, there are other com- 
mon messages the window may want to send. For example, 
distributed objects typically need to be told when their 
memory can be reclaimed. COM+ uses the well-known 
method releaseRef( ), whereas some implementations of 
CORBA use release( ). Regardless, this is a common mes- 
sage that would also need to be sent to the business objects, 
similar to the saveDataChanges( ) propagation above. 

Dirty Flag provides another example. Here, the window 
accumulates the results of dirty checking, as follows: 
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Account PaymentActivity::isDiity ( ) { 

//Return true if any single business object in the LUW is dirty, 
return 

(this.getAccount( ).isDirty( ) or 
this.getCustomer( ).isDirty( ) or 
this.getMonthlyBill( ).isDirty( ) or 
this.getBitlPayment( ).isDirty( ) ); 

} 



45 This hard-coded approach, although straightforward, is 
both tedious and error-prone. It is tedious because business 
developers shouldn't have to deal with technical issues like 
dirty checking or distributed garbage collection. They 
should focus instead on business-specific processing. 

so Moreover, this is error-prone because it can be difficult to 
detect if the developer makes a mistake. For example, a new 
requirement could make the window display address infor- 
mation. In addition to re-painting the window, the developer 
would also need to modify their hand-coded methods. But 

55 the developer might forget to update the isDirty( ) or release( 
) methods. Such errors can be difficult to locate. (Readers 
who have debugged memory leaks will certainly agree.) 

Instead, an architecture mechanism should encapsulate 
the propagation of these technical messages. When a mes- 

60 sage needs to be forwarded generically, to all objects in an 
LUW, the architecture should handle it. Such a capability 
would free business developers from worrying about these 
technical details. FIG. 183 illustrates a Hand-crafted Mes- 
sage Forwarding scheme. 

65 Therefore, an architecture "bag" will represent the busi- 
ness objects in a particular LUW. This bag, or collection, 
will hold onto each business object. Then, when the bag 
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receives a message like saveDataChanges( ) or release( ), it 
simply forwards the message to each member business 
object. 

FIG. 184 illustrates a Generic Message Forwarding fea- 
ture. 

Each LUW must have its own bag. This enforces the 
Isolation property (of ACID) for LUWs. That is, one LUW 
should not affect another LUW. For example, if the Account 
Payment and Account Services activities have separate 
LUWs, they will correspondingly have their own bags. 
Then, calling saveDataChanges( ) on the Account Payment 
activity will forward saveDataChanges{ ) to only those 
business objects owned by Account Payment. 

The bag also helps ensure the Atomicity property (also of 
ACID) for LUWs. It provides a single, atomic interface into 
the multiple business objects of the LUW. By design, it 
ensures that all business objects receive the same architec- 
ture messages. 

Thus, the scope of a bag is an LUW In addition, a bag 
provides contextual information for the LUW — i.e., which 
business objects that LUW uses. The architecture bag there- 
fore models the LUW Context, and will be named as such. 
Benefits 

Encapsulation. LUW Context hides technical details of 
persistence, garbage collection, etc., from business 
developers. Some of the Known Uses have managed to 
hide this framework, in entirety, from business logic. 

Robustness. This approach guarantees that each business 
object in the LUW receives forwarded messages. There 
is no longer the chance of a developer forgetting to 
include a particular business object in a group message. 

Application Maintainability. As the application require- 
ments change, the set of business objects in an LUW 
can change without impacting the generic, LUW code. 
For example, a future version of the Account Payment 
window could also display Address information. This 
introduces a new business object into the LUW. Yet it 
would not require updating saveDataChanges( ), or 
release( ) methods, as it would have previously. 

Performance. LUW Context can dramatically improve 
performance in a distributed environment. By nature, it 
batches up messages for a group. This can reduce 
network messaging. 

For example, consider a search window which has instan- 
tiated 30 business objects. Releasing those objects, if 
the messages were sent independently, would require 
30 network messages. However, with LUW Context, a 
single message can go from the client to the server. 
Then, within the server executable, the LUW Context 
forwards release( ) to the 30 member objects. This is far 
less costly than using the network for that messaging. 
Because of this message batching, some readers may 
confuse LUW Context with Request Batcher. It is true 
that both reduce the number of network messages. 
However, the former is concerned with supporting a 
family of generic, architecture messages, like isDirty( ) 
and refresh( ), on a single atomic object. The latter is 
concerned with grouping database requests into a 
physical package, for un-batching at the server. 
Although both have similar principles and 
characteristics, they solve different problems and are 
implemented differently. 

Architecture Extensibility. LUW Context models the 
LUW as an actual object in the software. Any other 
architecture processing which executes on a per- LUW 
basis can also be coded there. (See the Related Patterns 
section for examples.) 



This pattern seeks to hide the message propagation from 
business logic. In fact, messaging to an LUW Context can be 
hidden completely in an architecture superclass. Previously, 
saveDataChanges( ) would Ve been coded specifically in 
each concrete activity class. LUW Context allows it to be 
abstracted, as in: 
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AbstractLUWActivity::saveDataChanges( ) { 

//Propagate along the save message to all business 
//objects in my LUW. Subclasses don*t even need to 
//know about this method 

this.getLUWContextf ).saveDataChanges( ); 

} 
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This assumes that business objects were put into the LUW 
Context in the first place. The context object can be passed 
in when instantiating an object, transparently by the persis- 
tence and streaming frameworks, etc. 

An LUW Context can collaborate with a Request Batcher, 
if requests are batched for transmission to the data store. 
Rather than storing the batcher globally, each context and 
hence model can have its own manager. This allows multiple 
domain models, in multiple contexts, to send transactions 
simultaneously but independently. Then, whenever a busi- 
ness object requests an access or update, its request will be 
intercepted by the model's particular Request Batcher. The 
batcher then holds these requests until the activity — which 
owns the LUW — tells the batcher to send them. 

The LUW Context holds onto all domain objects in a 
particular model. It can therefore collaborate with an Iden- 
tity Registration Manager, to enforce object uniqueness 
within the particular context. 

The Potential Variables pattern, which provides local 
undo, is discussed in the first version of the Object Solutions 
Handbook. If local LUWs use this approach, then LUW 
Context is a natural location to store the LUW phase 
variable. 

In that pattern, every time a business object sets an 
attribute, the variable must be checked. The LUW Context, 
as intermediary, can provide a simple public interface which 
supports setting and querying the phase variable. 
Request Batcher 

FIG. 185 illustrates a flowchart for a method 18500 for 
batching logical requests for reducing network traffic. A 
group of business objects necessary for a transaction are 
provided and managed in a logical unit of work in operations 
18502 and 18504. In operations 18506 and 18508, logically- 
related requests received from the logical unit of work are 
grouped into a single network message which is then stored. 
The message is sent in operation 18510 upon receiving an 
order to send the message. 

Optionally, update and retrieval transactions may be 
grouped into a single network message which is stored. The 
message may be sent upon receiving an order to send the 
message. As another option, the requests from the message 
may be unpackaged at a point across a network and data 
changes may be persisted. In a further optional embodiment, 
responses to the requests may be received and the responses 
may be bundled into a reply. In one embodiment, the 
requests in the message may be sorted. In such an 
embodiment, the requests in the messages may also be 
separated into submessages. 

When domain objects request themselves, minimize the 
impact of network traffic. 

Individual Persistence assigns responsibility for data 
access to individual business objects. Then, each business 
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object can retrieve, update, insert, and delete its data from a obtained in operation 18806 and, in operation 18808, the 

persistent store independently of other objects. This pro- requests in the message are sorted and placed in a specific 

motes encapsulation and reuse across business transactions. order determined from the sorting rules and/or the sort 

FIG. 186 illustrates the manner in which the present weights. The sorted requests are batched into a single 

invention sends requests 18600 independently. 5 message which is sent to a data server where the requests are 

Thus, an LUW which uses multiple business objects will unbundled from the message in the specific order (see 

correspondingly have multiple requests. This might suggest operations 18810, 18812, and 18814). 

that each independent request communicate independently A request may also not be allowed to proceed until all 

with data access services. Then, each logical request would dependent requests are completed. A plurality of transac- 

translate into its own physical, network message. 10 tions may each use the same sorting rules for preventing 

Every network message imposes a certain amount of deadlocks. Optionally, the class represented by each request 

overhead, independently of its contentsor length. This may be determined so that the sorting rules may be based on 

implies that multiple, small-grained messages have more a class type. As another option, the sorting rules may include 

overhead than a single, large-grained message. Many referential integrity rules which ensure that references 

networked -constrained environments cannot tolerate this 15 between two relational tables are valid. In such a situation, 

additional overhead. Such environments should minimize a linear ordering of requests may also be created based on 

the impact of this network traffic. the referential integrity rules. The numbering of the position 

Therefore, a high-performance transaction should batch of the request in the linear ordering may also be the weight 

its logical requests into a single network message. Moreover, of that request so that requests with lower weights are 

a framework should handle this packaging, transparently to 20 processed before requests with higher weights, 

application logic. In an update transaction, order requests for referential 

FIG. 187 illsutrates a manner in which the present inven- integrity and deadlock avoidance, 

tion registers requests. Referential Integrity 

A Request Batcher 18700 object will group logically- Referential Integrity (RI) ensures that references between 

related requests. All requests will register with this coordi- 25 two relational tables are valid. That is, foreign keys in one 

nating object, rather than sending themselves immediately table must refer to existing primary keys in another table, 

and independently to their server or database. The batcher For example, RI rules could require that all accounts have a 

will then store these requests together, until told to send customer. Then, values in account.cust id would need 

them as a unit. This batching applies equally well to update matching values in customer.cust__id. 

and retrieval transactions. 30 Mission-critical RDBMSs can enforce RI at run-time. 

A corresponding Request "Unbatcher" 18702 on the Then, if a modified foreign key does not match an existing 

server will unpackage the bundled network message. primary key, the database prevents the update. 

Finally, this Unbatcher will bundle the network response and Continuing the example, a transaction may insert a new 

send it back to the Request Batcher. customer and its new account. If the transaction inserts the 

Benefits 35 account first, account.cust_Jd will refer to a non-existent 

Performance. Sending a single message of multiple customer. The RDBMS will raise an error, thereby failing 

requests, as opposed to multiple messages of single tne transaction. Instead, the account request should run after 

requests, improves communication performance. the customer request. 

Dynamic. Batching and sorting requests is transparent to Deadlock Avoidance 

the requests themselves. Requests do not know that a 40 Even without RI, request ordering remains an issue, 
particular transaction contains them. This dynamic Imagine a transaction A orders customer before account, 
relationship allows any type of request to be part of any Conversely, a concurrent transaction B orders account 
transaction at run-time before customer. A will request a lock on the customer table, 
. * i . L „ j while B will request a lock on the account table. A must wait 
Scaleabihty. In an asynchronous or multi-threaded 45 for B to complete and release its account lock. Yet B cannot 
environment, an application could use multiple Request ^ ^ A feleases ^ bck 
Batchers. For example each LUW could have its own ^ both deadlock. Many transaction- 
batcher A batcher needs to store state while budding si tems would si x fail ^ transactioDS , 
the batch, as requests register. Using multiple instances after a ^_ QnX Yet both transactions othe rwise have 
facilitates registration for, and sending of, multiple 5Q beeQ WB ^^ 
batches simultaneously. Users can then multi-task Traditional Approach 

while other, time-consuming requests process in the TradiU onally, transactions have hard-coded deadlock 

°* ' avoidance and RI. Each transaction has called its own update 

This simultaneity can also be supported with one, multi- module. Each hand-crafted module has ordered multiple 

threaded batcher. In this case, each request registers 5S SQL statements, according to these rules, 

along with its unique transaction id. However, with Individual Persistence, a transaction no 

Centralization. The batcher has visibility over all requests longer maps to a centralized module. Instead, independent 

in the LUW. This provides a centralized point to sort requests register for the transaction in an ad-hoc manner, 

these requests, thereby supporting referential integrity FIG. 189 illustrates an Ad Hoc Registration feature, 

and deadlock avoidance. 60 Moreover, an account has no hard-coded "knowledge" 

Request Sorter that it should persist after a customer. This independence 

FIG. 188 illustrates a flowchart for a method 18800 for provides flexibility any business object can request an 

sorting requests that are being unbatched from a batched update without concern for other business objects. A frame - 

message. A group of business objects necessary for a trans- work which constrains the request order must support this 

action are provided in operation 18802. Logically-related 65 flexibility. 

requests received from the business objects are grouped in Therefore, an update transaction should sort its requests 

operation 18804. Sorting rules and/or sort weights are before sending them to the data server. The sorted result will 
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conform to RI rules. Then, across update transactions, all cannot be sorted as a group. Request Batcher provides a 

customer requests can appear before all account requests. In centralized place to attach a sorter, 

addition, every transaction will use the same sort algorithm. Separate Models 

That will prevent deadlocks. FIG. 191 illustrates a flowchart for a method 19100 for 

Multiple requests can no longer send themselves directly 5 assigning independent copies of business data to concurrent 

to the server, in an ad hoc fashion. Instead, they must register logical units of work for helping prevent the logical units of 

with a centralized object, which can sort them first. A work from interfering with each other. In operation 19102, 

centralized Request Sorter will order multiple requests multiple logical units of work operating concurrently are 

before finally sending the transaction. provided. Each of the logical units of work manipulate at 

FIG. 190 illsutrates a manner in which the present inven- 10 least one common business object. In operation 19104, a 

tion sorts requests by weight. copy °f me common business object is created for each of 

The sorter 19000 will have visibility to sorting rules, or the logical units of work such that the copy of the business 

even weights, to determine this order. The rules can typically ^J^ 1 for one lo si cal UQ it of work becomes a separate 

be based on the class type. Before sending the transaction, is mstance from the of the business ob j ec * for another 

the sorter can ask each request which class it represents. In lo S lcal umt of work * ^ of the business ob i ect knows 

this manner, the sorter can re-order the requests appropri- * e 00016x1 ° f , that °<W of ? c b f incss ob j ect m relation t0 
. the associated logical unit of work. Upon receiving a request 

Benefits t0 ma ^ G cnan S es t0 a c°py °f tne business object of one of 

20 the logical units of work in operation 19106, that particular 
Separation of Concern. This sorting pattern hides the of the business object is cha d whUe the Qther ies 

technical details and complexity of RI from business of me busmess object afe nQt cfaa d h ^ tfaen verified m 
logic. Apphcations avoid hard-wiring customized RI «• imno .1 . i c . , 

rules for its transactions. operation 19108 that only one copy of the busmess object 

w • . • m i -i u i- * . . . has been changed and the common business object is 

Maintainability. RI rules can easily be changed without _ c , , . . 

impacting application code. Granted, this does not 25 updated m operaUon 19110 based on the change to the copy 

happen frequently in production. of the business object. 

Reusability. The generic Request Sorter uses universal Abusiness object may optionally be passed as a parameter 

sorting rules, or weights. These rules are global across from one context to another. In such case, a context copy of 

business processes. Moreover, the rules are based on 30 tne business object may be created which includes a dupli- 

existing, reusable business objects. Therefore, new cate of the original data and excludes a context variable. As 

applications can reuse the sorter, as well. another option, an exception may be thrown when an 

Visibility. If RI enforcement is distributed across appli- attempt is made to create a copy of a business object being 

cation logic, it can be difficult to get a complete picture altered by one logical unit of work for another logical unit 

of the referential rules. Request Sorter centralises those 35 of work. 

rules (i.e. weights) in one, visible place. ^ business object may also be sent to another context as 

A complete, linear ordering of all domain classes can be at least Qne of a single focus of a ^ ^ bemg 

created, based on the RI rules. Each class will have a unique Cfeated and a parameter in an explicit param eter-passing 

position in the ordering. Tliis position is the class 1 weight for mec hanism. Additionally, the copies of the business objects 

the sorting algorithm. Requests for domain objects with « may be Cfeated from a same retrieved data stream ^ a 

lower weights will always appear before requests with further option, receiving a request to make changes to a copy 

higher weights. 0 f me busmess object of one of the logical units of work and 

For example, consider the ordering: changing that copy of the business object may further 

27. . . . 45 include the broadcasting of the change to the other logical 

28. Customer units of work. 

29. MeterRead Support multiple business LUWs within an MVC-based 

30. Account architecture. Manage these LUWs concurrently yet 

31. Meter separately, thereby preserving the Isolation property of 

32. MonthlyBill 50 ACID. 

33. . . . Multi-tasking allows the user to complete several different 
This satisfies the RI rule mentioned earlier, because business functions independently of each other. Those func- 

Customers have a lower weight (28) than Accounts (30). tions which are business LUWs must process concurrently 

Thus, requests for customers will appear in any transaction 55 yet separately. For example, a user could establish a new 

before requests for accounts. As long as the order satisfies customer account while separately verifying bill details for 

every RI rule, the request sorter can use such a linear another customer. 

ordering. Providing for these multiple LUWs demands mechanisms 
Th is sort orderi ng can be created programmati call y. A sort which ensure integrity. Specifically, as with any LUW, a 
generator can convert pairwise relationships into linearly- 60 primary LUW must isolate its own changes. It is an inde- 
ordered weights. Then, the Request Sorter could use an pendent workspace which prevents its changes from affect- 
algorithm like Quicksort to do the actual sorting. ing other LUW. 

(Alternatively, object requests could be sorted as they are However, an MVC-based OO architecture does not natu- 

registered, a la Insertion Sort.) 65 rally support this requirement. With MVC, the domain 

A centralized store-and-forward site must hold requests, model stores all data changes. Windows are merely a view 

before they send themselves to the server. Otherwise they into this model, and they have little business data of their 
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own. In addition, MVC model objects have no idea which 
views are using them. Instead, the model anonymously 
broadcasts its data changes, and all views on the model 
respond by updating themselves. This synchronizes win- 
dows with their business data. Thus, MVC allows multiple 5 
views to simultaneously display, and be refreshed by, a 
single copy of the model data. 

FIG. 192 illustrates the MVC Implementation with Global 
Model. 10 

Unfortunately, this benefit of MVC introduces a problem. 
A globally-shared domain model does not naturally separate 
concurrent LUWs. It puts a burden on business "activity" 
objects, which coordinate the high-level business processing 
across their domain models. Each activity has to either avoid 15 
overlap or know specifically how it affects the model. 

Consider a telecommunications system, with two separate 
business LUWs for paying bills and adding new services, 
like call waiting. An end user might launch windows for 2 q 
these two LUWs simultaneously. This would allow the user 
to multi-task while conversing with the customer. 

Both windows display Account and Customer informa- 
tion. In addition, the Account Services window actually 
modifies the Account object, whereas the Account Payment 25 
window does not. Making a payment only modifies the Bill 
Payment object. Both windows, using MVC, could share the 
same Account 101 instance. 

It is not atypical for custom architectures to have generic 3Q 
mechanism for persistence and transactions. For example, 
the architecture could use a straightforward mechanism 
which automatically saves all business objects within an 
LUW. Then, when the user saves the Account Payment 
window, the changes to Account 101 would be accidentally 35 
saved as well. The user would then not be able to later cancel 
changes on the Account Services window. This violates the 
isolation of the two LUWs. 

A similar problem might arise with a garbage collection ^ Q 
framework, which explicitly destroys all instances once the 
LUW has completed. In this case, Account Payment would 
need to ensure it did not explicitly free the memory for 
Account, while Account Services was still using it. 

Therefore, using a global, MVC model may preclude 45 
using other architecture mechanisms. To avoid the problems 
of overlapping saves or releasing memory prematurely, the 
windows could have additional code to ensure the LUWs 
remain separate. However, adding application-specific code 
in this manner, to handle a global technical requirement, is 50 
undesirable. 

Instead, business LUWs should be able to modify domain 
data independently of each other, transparently in the archi- 
tecture. In addition, each data change should unambiguously 55 
belong to a single, originating LUW. 

Modern Object Transaction Monitors promise to provide 
this capability. These products will handle locking, tracking 
which LUW has made changes to which piece of data, etc. 
However, in the absence of an OTM, a custom architecture 60 
needs a different approach. 

Therefore, separate business LUWs by giving each LUW 
separate copies of business data. 

Rather than using a globally-shared model, each business 65 
LUW will own a private, scratchpad copy of its domain 
model. This satisfies the independence requirement. Abusi- 



,068 Bl 

308 

ness object in one model will automatically be a separate 
instance from a business object in another model, even if 
they share the same functional identity. For example, simul- 
taneously opened payment and services windows would 
have separate copies of Account 101. 

Then, changes made to a particular instance will only be 
reflected in the LUW which created and points to that 
instance. This contrasts with a single, globally-shared 
model. The latter would simultaneously reflect changes 
across multiple LUWs. 

FIG. 193 illustrates the Separate Models for Separate 
Business LUWs 19300,19302. 

The aforementioned telecommunications example had 
two separate business LUWs for the account payment and 
account services functions. Although both activities may be 
related by the same logical account, this pattern gives each 
a different context copy. Then, when the customer represen- 
tative cancels the addition of call waiting, she can still save 
the payment details. 

FIG. 194 illustrates the Canceling of one LUW 19400 
Independently of Another LUW 19402. 

Thus, using Separate Models preserves the integrity of 
business LUWs. It allows each LUW to easily save or cancel 
independently. 

This pattern is not intended to allow different LUWs to 
simultaneously change their different physical copies of the 
same logical entity. In fact, if both windows modified their 
Account 101 copy, one of the LUWs would fail. 
(Mechanisms like optimistic locking would detect the data 
integrity conflict.) 

Precisely for this reason, a good UI design doesn't typi- 
cally allow simultaneous but separate LUWs to update the 
same data. And this was not an issue in the example above. 
Updates to the Account object occur on the Account Ser- 
vices window but not the Account Payment window. 
Benefits 

Isolation. Most fundamentally, this pattern solves the 
Isolation requirement of ACID. It ensures that each 
LUW has its own "working storage" copies of business 
data. 

Transparency. Separating models can be done in an archi- 
tected fashion, as outlined in the implementation sec- 
tion. The separation of LUWs — which is a technical 
issue — can be hidden completely from business logic. 

Imagine instead that LUWs didn't have their own copies. 
Then, each operation might need an additional argu- 
ment: the LUW owning the data change. This would 
pollute application code with an extra "transaction ID" 
argument, as in setBalance(newBalance, 
transactionld). As previously mentioned, this is only 
required in the absence of an Object Transaction Moni- 
tor. An OTM can transparently manage the transaction 
Id with the thread, without including it as an explicit 
argument. 

Uniformity. Application developers don't need to know 
about which objects may or may not be used by other, 
concurrent LUWs. 
The following implementation assumes that the LUW 
Context pattern is used to help separate the LUWs. 

Each instance of a business object knows which LUW 
owns it. That is, each instance knows its context. By 
definition, context gives something a scope, a frame of 
reference, a relationship to other things. To provide this 
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relationship, an actual LUW Context object will hold onto object cannot live in two different contexts. Otherwise, 

business objects which share a business LUW. changes made to that instance would affect two different 

In addition, each business object can point to its context. LUWs. 

In thai manner, business objects know their LUW. This „ fa of , eD Decess however) t0 a busioess ^ ^ 

could be useful, for example, while building a domain 5 a rameter from one to For e le> a ^ 

model. Then, the parent object could propagate its context to m t , t .. . , , , , t . 

a linked child object may open up a customer details window based on a selection 

« . ' .. J.. . • Tirt./L from a search window. The selected customer becomes the 

Business objects owned by the same business LUW snare c . , . , , . 

„ . . , t r Im , . iocus of the new window, but it was instantiated in the 

the same LUW Context, whereas different LUWs have . _ . , . , 

, . , T- i » . ,u r * • ™ io search context. It is the responsibibty of the details window 

different contexts. Each context therefore contains its own . . , . 

"working-storage" copy of the model. This delineates an !° ' ake lhe P 355 ^-" 1 ^tomer and make a context copy of 

, , . » ac if* rii / it. A context copy duplicates the original s data, excluding 

individual workspace, or scratchpad, for each LUW. ^. , . _ _ _ * 

. t . . . * . . ... . the context variable, which is re-set to the new context. The 

At a higher level, each activity object which represents a . , 4 . . c . . . ,. c , ... 

. . , . . copied customer can then be safely used and modified within 

busmess LUW has its own context object. That context 15 ^ details context 
remains with the activity throughout its entire lifecycle. For 

...... .. t im/ . ■* i . A business object can be passed as parameter to another 

initialization, creating a new LUW activity also creates a j r 

context as' 

new context instance for that activity. This context will then 

be passed downwards, to all business objects, as part of the single focus of a window that is being created 

navigation. 20 a parameter in an explicit parameter-passing mechanism 

Eventually, when the activity closes, it releases its LUW For example, when a business object is the focus of a new 

Context. This correspondingly releases all business objects. activity, the launching activity could instantiate the new 

They can then be garbage collected, because the only LUW activity as follows: 



MeterMaintenanceActivity::prorateMeterRead( McterRcad aMctcrRcad ) 
< 

// Creates a new activity to prorate <aMeterRead>. This will manually adjust 

the 

// read charges, based on corrections from the location, the office, etc. 
// Pseudo-code below. 

// Create the new activity instance by reflection, based on the class name, and 
// give it a new context and <aMeterRead> as focus. 
newProrateActivity - this.newActivity( 

th_s.prorateMeterReadClassName( ), 

aMeterRead ); 
// Other initialisation here ... 
newProrateActivity.staitup( ); 



using those objects just closed. A context's lifecycle there- 
fore corresponds directly to its activity's lifecycle. 

Preserving Context Boundaries 

Every context has a scope which limits the business LUW. 
This context boundary cannot be violated with objects from 
other LUW Contexts. For, the same instance of a business 



The newActivity( ) architecture method instantiates a new 
activity, instantiates a new context, and creates a context 
copy of aMeterRead that the new activity can use. 

Sometimes an activity cannot get enough information 
45 simply by navigating from the focus. Non-focus information 
that must be passed as an additional parameter could be 
handled in the following manner: 



Mete rMainte nance Activity ::prorale Mete rReadWithCorrection( 

MeterRead originalMeterRead, MeterRead correctedMeterRead ) 

{ 

// Creates a new activity to prorate <origlnalMeterRcad> based on 
measurements 

// in <correctedMeterRead>. Pseudo-code below. (Duplicates some 
code above 

// for clarification.) 

// Create the new activity instance by reflection, based on the class 
name, and 

// give it a new context and <orig_nalMeterRead> as focus. 
newProrateActivity = this.newActivity( 

this.prorateMeterReadClassName( ), 

original MeterRead )r, 
U Pass along the corrected read, as well. This will create a context 
copy and 

// then use reflection to call the right public setter on the activity. 
newProrateActivity. receive( aCo rrectedMete rRead, 
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-continued 



"setCoirectedRead" ); 

// Other initialisation here ... 
ncwProratcActivity.startup( ); 

} 



Here, the receive( ) framework method allows any busi- 
ness object to be passed across the context boundary. The 10 
receiving activity will automatically create a context copy 
and then call the specified setter method, with the copy as 
argument. The setter is application-specific, and it allows the 
activity to handle and store the context copy wherever it 
wants. is 

FIG. 195 illustrates the Context Copying Protects Context 
Boundaries. 

A dirty object should not be safely copied into a new 
LUW context. Otherwise, the second LUW would begin 
using information that was half -completed in the first LUW. 20 
Again, this violates the isolation requirement. The second 
LUW could save its changes before the first LUW. This 
means the first LUW couldn't undo any changes it had made 
to the dirty object. Instead, to avoid this problem, an 
exception should be thrown when trying to copy dirty 
objects across contexts. This disallows users from beginning 25 
a new LUW based on half-entered data. 

Thus, context copying allows LUW contexts to share 
parameter information while preserving context boundaries. 
Persistence Caching 

Although LUW contexts manipulate separate copies of 30 
business objects, they can often share the same retrieved 
data stream. For example, when a workstation retrieves data 
for Customer ABCD, the returned stream can be stored in a 
global cache. If another context wants to later instantiate its 
own copy of Customer ABCD, it can reuse the details stored 35 
in the stream cache. This improves performance, by avoid- 
ing a redundant request to the remote data store. 
Context "Refresh" 

Each LUW, while working on its data, is independent of 
the other LUWs. From that perspective, each LUW context ^ 
manipulates data that, to its knowledge, is the most current 
information from the data store. One instance's changes 
remain invisible to another copy of the same business entity, 
during the course of normal processing. 

However, when an LUW context successfully commits 
changes, it will have more current data than other contexts 45 
which it intersects. This up-to-date data can be broadcast and 
shared with the other contexts. These contexts can then 
decide to transparently incorporate the changes or not. 

This refresh mechanism can be complex to build, and it 
requires an understanding of locking issues. For example, 50 
does the window have any changed data which might 
conflict with the new data? This would make the changes 
which hadn't yet been committed invalid, and the user 
would need to be notified. 

Although only a few embodiments of the present inven- 55 
tion have been described in detail herein, it should be 
understood that the present invention may be embodied in 
many other specific forms without departing from the spirit 
or scope of the invention. Therefore, the present examples 
and embodiments are to be considered as illustrative and not 60 
restrictive, and the invention is not to be limited to the details 
given herein, but may be modified within the scope of the 
appended claims. 

What is claimed is: 

1. A method for distributing incoming requests from a 65 
client amongst server components for optimizing usage of 
resources, comprising the steps of: 



(a) receiving incoming requests from a user interface, 
wherein the user interface resides on a client and the 
requests are received by an activity module, and 
wherein the activity module instructs the client to 
handle a first subset of the requests on the client and the 
activity module forwards a second subset of the 
requests to a utilization-based load balancer, such that 
the activity module resides between the user interface 
and a plurality of server components; 

(b) storing the second subset of the requests on the load 
balancer upon receipt thereof from the activity module; 

(c) determining an availability of server components from 
among the plurality of server components; 

(d) compiling a listing of available server components; 

(e) determining which server component on the listing of 
available server components is most appropriate to 
receive each of the second subset of the requests, 
wherein the load balancer calculates an amount of 
utilization that each available server component is 
currently experiencing wherein the amount of utiliza- 
tion of each available server components is calculated 
based on at least two of: current CPU utilization, kernel 
scheduling run-queue length, current network traffic at 
a node to the server component, and a number of 
requests currently being serviced; and 

(f) sending each of the second subset of the requests to the 
selected server component determined to be most 
appropriate to receive each of the second subset of the 
requests. 

2. A method as recited in claim 1, wherein the step of 
determining which server component is the most appropriate 
is performed by allocating the request on a round-robin 
whereby requests are assigned to consecutive server com- 
ponents by traversing along the listing of available server 
components. 

3. A method as recited in claim 1, further comprising the 
step of rerouting a request to a different available server 
component upon a crash of the selected server component. 

4. A method as recited in claim. 1, further comprising the 
step of saving the server components in a persistent store, 
wherein a check is made to determine whether a connection 
to a server component needs to be reestablished. 

5. A computer program embodied on a computer readable 
medium for distributing incoming requests from a client 
amongst server components for optimizing usage of 
resources, comprising the steps of: 

(a) a code segment that receives incoming requests from 
a user interface, wherein the user interface resides on a 
client and the requests are received by an activity 
module, and wherein the activity module instructs the 
client to handle a first subset of the requests on the 
client and the activity module forwards a second subset 
of the requests to a utilization-based load balancer, such 
that the activity module resides between the user inter- 
face and a plurality of server components; 

(b) a code segment that stores the second subset of the 
requests on the load balancer upon receipt thereof from 
the activity module; 
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(c) a code segment that determines an availability of 
server components from among the plurality of server 
components; 

(d) a code segment that compiles a listing of available 
server components; 

(e) a code segment that determines which server compo- 
nent on the listing of available server components is 
most appropriate to receive each of the second subset of 
the requests, wherein the load balancer calculates an 
amount of utilization that each available server com- 
ponent is currently experiencing wherein the amount of 
utilization of each available server components is cal- 
culated based on at least two of: current CPU 
utilization, kernel scheduling run-queue length, current 
network traffic at a node to the server component, and 
a number of requests currently being serviced; and 

(f) a code segment that sends each of the second subset of 
the requests to the selected server component deter- 
mined to be most appropriate to receive each of the 
second subset of the requests. 

6. A computer program as recited in claim 5, wherein the 
code segment that determines which server component is the 
most appropriate is performed by allocating the requests on 
a round-robin basis whereby requests are assigned to con- 
secutive server components by traversing along the listing of 
available server components. 

7. A computer program as recited in claim 5, further 
comprising a code segment that reroutes a request to a 
different available server component upon a crash of the 
selected server component. 

8. A computer program as recited in claim 5, further 
comprising a code segment that saves the server components 
in a persistent store, wherein a check is made to determine 
whether a connection to a server component needs to be 
reestablished. 

9. A system for distributing incoming requests from a 
client amongst server components for optimizing usage of 
resources, comprising the steps of: 

(a) logic that receives incoming requests from a user 
interface, wherein the user interface resides on a client 
and the requests are received by an activity module, and 
wherein the activity module instructs the client to 
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handle a first subset of the requests on the client and the 
activity module forwards a second subset of the 
requests to a utilization-based load balancer, such that 
the activity module resides between the user interface 
and a plurality of server components; 

(b) logic that stores the second subset of the requests on 
the load balancer upon receipt thereof from the activity 
module; 

(c) logic that determines an availability of server compo- 
nents from among the plurality of server components; 

(d) logic that compiles a listing of available server com- 
ponents; 

(e) logic that determines which server component on the 
listing of available server components is most appro- 
priate to receive each of the second subset of the 
requests, wherein the load balancer calculates an 
amount of utilization that each available server com- 
ponent is currently experiencing wherein the amount of 
utilization of each available server components is cal- 
culated based on at least two of: current CPU 
utilization, kernel scheduling run-queue length, current 
network traffic at a node to the server component, and 
a number of requests currently being serviced; and 

(f) logic that sends each of the second subset of the 
requests to the selected server component determined 
to be most appropriate to receive each of the second 
subset of the requests. 

10. A system as recited in claim 9, wherein the logic that 
30 determines which server component is the most appropriate 

is performed by allocating the requests on a round-robin 
basis whereby requests are assigned to consecutive server 
components by traversing along the listing of available 
server components. 

11. A system as recited in claim 9, further comprising 
logic that reroutes a request to a different available server 
component upon a crash of the selected server component. 

12. A system as recited in claim 9, further comprising 
logic that saves the server components in a persistent store, 
wherein a check is made to determine whether a connection 
to a server component needs to be reestablished. 
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